Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #3764 > unrolled thread

There is still a problem with SpinLock...

Started byaminer <aminer@toto.net>
First post2013-09-23 03:51 -0700
Last post2013-09-23 11:39 -0700
Articles 3 — 2 participants

Back to article view | Back to comp.programming


Contents

  There is still a problem with SpinLock... aminer <aminer@toto.net> - 2013-09-23 03:51 -0700
    Re: There is still a problem with SpinLock... aminer <aminer@toto.net> - 2013-09-23 04:18 -0700
    Re: There is still a problem with SpinLock... "Chris M. Thomasson" <no@spam.invalid> - 2013-09-23 11:39 -0700

#3764 — There is still a problem with SpinLock...

Fromaminer <aminer@toto.net>
Date2013-09-23 03:51 -0700
SubjectThere is still a problem with SpinLock...
Message-ID<l1ortb$5sm$1@news.albasani.net>
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.

[toc] | [next] | [standalone]


#3765

Fromaminer <aminer@toto.net>
Date2013-09-23 04:18 -0700
Message-ID<l1othi$92q$1@news.albasani.net>
In reply to#3764
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.










[toc] | [prev] | [next] | [standalone]


#3767

From"Chris M. Thomasson" <no@spam.invalid>
Date2013-09-23 11:39 -0700
Message-ID<l1q1ts$on3$1@speranza.aioe.org>
In reply to#3764
> "aminer"  wrote in message news:l1ortb$5sm$1@news.albasani.net...

[...]

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.6490

BTW, you don't need DWCAS to implement this...

https://groups.google.com/forum/#!original/comp.arch/aLVoxdQdRac/micVZJgOjdUJ 

[toc] | [prev] | [standalone]


Back to top | Article view | comp.programming


csiph-web