| comp.programming.threads@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
| Ramine <ramine@1.1>: Nov 02 01:37PM -0800 Hello... I have updated my lightweight SemaCondvar and SemaMonitor, they were compiling correctly for windows 32 bit platform with Delphi XE versions, and now they are compiling correctly for windows 64 bit platform with Delphi XE versions, the version is the same at 1.21. Please download it again... I have compiled my SemaMonitor for Windows 64 bit platform and I have benchmarked it against the Windows Semaphore and i have noticed that the Windows semaphore is only 34% faster than my SemaMonitor, that's the same for my SemaCondvar, but notice with me that my SemaMonitor and SemaCondvar synchronization objects are more powerful than the Windows Semaphore, so all in all i have invented those new concepts and implemented them efficiently and correctly , so hope you will be happy with them. You can download my lightweight SemaMonitor and SemaCondvar that are faster from: https://sites.google.com/site/aminer68/light-weight-semacondvar-semamonitor Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Nov 02 10:34AM -0800 Hello, What i have done correctly is that i have lowered the standard deviation of the throughtput of my scalable MLock (it is a scalable lock)... what do i mean by that ? you have to be careful when you are using Ticket spinlock with a proportional backoff , cause when there is many more threads contending for the Lock, the threads that didn't yet received there ticket to enter and that are scheduled to run , will use all there quantum time(time slice), so they will slow the throughput by much and they will genrate a bigger standard deviation on there thoughtput..so what you have to do is use for example a windows sleep(0) after the proportional backoff to give up the time slice as soon as possible and this will lower by much the standard deviation of the thoughput of the Ticket spinlock with a propotional backoff... i have used the same technic for my scalable MLock and it is giving a much smaller standard deviation for its throughput...and this has solved the same problem on my SemaMonitor and SemaCondvar , using my technic allowed the standard deviation of there throughput to be lowered a lot... so you have to be smart please and make sure you avoid those problems... Here is the source code that i am using to lower the standard deviation of the throughput of my scalable MLock, and it is working perfectly... -- inc(k); if (k mod 140)=0 then {$IFDEF FPC} ThreadSwitch; {$ENDIF} {$IFDEF Delphi} sleep(0); {$ENDIF} - Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Nov 02 08:57AM -0800 Hello, I have just benchmarked my SemaMonitor against the Windows Semaphore, and the Windows Semaphore is only 37% faster than my SemaMonitor, I compiled it for Win64 platform and my SemaMonitor is faster on it, so i think my SemaMonitor and my SemaCondvar are useful and powerful synchronization mechanisms. SemaCondvar and SemaMonitor are new and portable synchronization objects , SemaCondvar combines all the charateristics of a semaphore and a condition variable and SemaMonitor combines all charateristics of a semaphore and an eventcount , they only use an event object and and a very fast and very efficient and portable FIFO fair Lock , so they are fast and they are FIFO fair. Now you can pass the SemaCondvar's initialcount and SemaCondvar's MaximumCount to the construtor, it's like the Semaphore`s InitialCount and the Semaphore's MaximumCount. Like this: t:=TSemaMonitor.create(true,0,4); When you pass True in the first parameter of the constructor the signal(s) will not be lost even if there is no waiting threads, if it's False the signal(s) will be lost if there is no waiting thread. Here is the methods that i have implemented : TSemaCondvar = class public constructor Create(m1:TCriticalSection;state1:boolean=false;InitialCount1:longword=0;MaximumCount1:longword=INFINITE); destructor Destroy; override; function wait(mstime:longword=INFINITE):boolean; procedure signal();overload; procedure signal_all(); procedure signal(nbr:integer);overload; function WaitersBlocked:integer; end; TSemaMonitor = class public constructor Create(state1:boolean=false;InitialCount1:longword=0;MaximumCount1:longword=INFINITE); destructor Destroy; override; function wait(mstime:longword=INFINITE):boolean; procedure signal();overload; procedure signal_all(); procedure signal(nbr:integer);overload; function WaitersBlocked:integer; end; You can download my lightweight SemaCondvar and Semamonitor that are faster from: https://sites.google.com/site/aminer68/light-weight-semacondvar-semamonitor Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Nov 02 09:10AM -0800 I wrote: "SemaMonitor combines all charateristics of a semaphore and an eventcount" In fact my SemaMonitor is more powerful than that, cause when you pass True in the first parameter of the constructor the signal(s) will not be lost even if there is no waiting threads, if it's False the signal(s) will be lost if there is no waiting threads. That the same for my SemaCondvar. Hope this is clear now. Than you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Nov 02 07:53AM -0800 Hello, "In NUMA machines, the HCLH lock and the cohort locks perform much bettern in terms of the locality while most queue lock except the HCLH work better in the performance." Read more here: https://cs.brown.edu/research/pubs/theses/masters/2012/ma.pdf Thank you, Amine Moulay Ramdane. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
No comments:
Post a Comment