Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #1728 > unrolled thread
| Started by | aminer <aminer@toto.net> |
|---|---|
| First post | 2013-09-23 03:51 -0700 |
| Last post | 2013-09-23 11:39 -0700 |
| Articles | 3 — 2 participants |
Back to article view | Back to comp.programming.threads
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
| From | aminer <aminer@toto.net> |
|---|---|
| Date | 2013-09-23 03:51 -0700 |
| Subject | There 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]
| From | aminer <aminer@toto.net> |
|---|---|
| Date | 2013-09-23 04:18 -0700 |
| Message-ID | <l1othi$92q$1@news.albasani.net> |
| In reply to | #1728 |
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]
| From | "Chris M. Thomasson" <no@spam.invalid> |
|---|---|
| Date | 2013-09-23 11:39 -0700 |
| Message-ID | <l1q1ts$on3$1@speranza.aioe.org> |
| In reply to | #1728 |
> "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.threads
csiph-web