About my RWLock ...

[aminer]

Hello,


If you take a look at the SpinLock that i am using
inside my SemaMonitor, it uses a backoff mechanism to be more efficient but there is still a weakness with that SpinLock cause
all the threads inside this SpinLock spin on the same shared location causing
cache-coherence traffic on every successful lock access so it will slow globally the threads of your computer, so the idea is to use like an MCS queue Lock that uses
an exponential backoff and that doesn't spin on a shared variable but
local variables.

I am not the designer of this SpinLock, this SpinLock was designed by other devellopers and it is not so efficient as i have just explained, here is the
devellopers of this SpinLock (that i am using) called Istvan Agoston and Primoz Gabrijelcic :

here  http://code.google.com/p/gpdelphiunits/source/browse/trunk/src/SpinLock.pas?r=37


So i will try to design something like an MCS queue lock that
is very efficient in the near future nad that i will use inside
my SemaCondvar and SemaMonitor.


Thank you,
Amine Moulay Ramdane.

[aminer]

Hello,

This SpinLock that i am using will not impact the performance of
my RWLock cause to use effectivly my RWLock there must be far less a fewer number of writers than readers. But it will impact the performance of my SemaCondVar and SemaMonitor, so i will design something that look like an MCS queue Lock and that is
more efficient than this SpinLock with a backoff mechanism,
and as i said before we  have to spin on local variables not on shared variable and use a backoff mechanism this way our Lock will be
very efficient.


Thank you,
Amine Moulay Ramdane. 

[aminer]

On 9/22/2013 11:37 PM,
aminer wrote:

> This SpinLock that i am using will not >impact the performance of my RWLock.

i mean will not impact negatively the performance of my RWLock.



Thank you,
Amine Moulay Ramdane.

[aminer]

I correct:

Hello,

This SpinLock that i am using will not impact negatively  the performance of
my RWLock cause to use effectivly my RWLock there must be far less and fewer number of writers than readers. But it will impact negatively when there is high contention the performance of my SemaCondVar and SemaMonitor, so i will design something that look like an MCS queue Lock and that is
more efficient than this SpinLock with a backoff mechanism,
and as i said before we  have to spin on local variables not on shared variable and use a backoff mechanism this way our Lock will be
very efficient.


Thank you,
Amine Moulay Ramdane.

[aminer]

Hello,

About the following SpinLock that i am using inside my SemaMonitor and SemaCondvar:

 http://code.google.com/p/gpdelphiunits/source/browse/trunk/src/SpinLock.pas?r=37


I think it's not so bad and it can give a decent performance even under high contention cause it uses a backoff mechanism, and even though it spins
on shared variables and not on local variables causing more cache-coherence traffic, i don't think it will slow substantially and globally the threads of your computer, hence
i think this TTAS spinlock  with an exponential that i am using  have a decent performance inside my SemaCondvar and SemaMonitor even under high contention, so no need for an MCS queue Lock.


So enjoy my SemaCondvar and my SemaMonitor and my scalable RWLock cause they are fast.

You can download them from:

http://pages.videotron.com/aminer/


Thank you,
Amine Moulay Ramdane.

[aminer]

Hello,

That's not the end of the story, there is still a problem with the SpinLock that i am using, it's a TTAS with an exponential backoff but this kind
of spinlock suffers from starvation, i mean that some threads may starve for a long time and this is not acceptable, and i think
that the lockfree algorithms that spin on a CAS suffers from the same
problem that is starvation, so the solution is to use a Ticket Spinlock with backoff that is fair to resolve the starvation problem , but this kind of Ticket Spinlock spins on a shared variable and this higher the cache-coherence traffic, so this will slow the system globally so this is not
so efficient, so the MCS queue Lock is the solution i think.

But i have still a question for you:

Does the Windows critical section suffers from this starvation problem
and does it uses a TTAS with backoff or is it the same as an MCS queue Lock or ..?



Thank you,
Amine Moulay Ramdane.

[aminer]

Hello,

I have asked you about Windows critical sections and the starvation
problem, and i have just read the following:


"The change to unfair locks clearly has the risk of leading to starvation.  But, statistically speaking, timing in concurrent systems tends to be so volatile that each thread will eventually get its turn to run, probabilistically speaking.  Many more programs would suffer from the convoy problems resulting from fair locks than would notice starvation happening in production systems as a result of unfair locks."

read here:

http://joeduffyblog.com/2006/12/14/anticonvoy-locks-in-windows-server-2003-sp1-and-windows-vista/


So as you have noticed the Windows critical section has become unfair
and since it has become unfair starvation can happen now with windows
critical section etc. so some threads may starve for a long time and this not acceptable i think, and not acceptable for me.


Thank you,
Amine Moulay Ramdane.