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

Groups > comp.programming.threads > #2324

This PH.D doctor don't seem understand

Cross-posted to 2 groups.

Show all headers | View raw

Hello,

Read this:


http://concurrencyfreaks.blogspot.ca/2014/05/c11-atomics-and-mpsc-mutual-exclusion.html 


They say this:

--
"This may remind you of the MCS Lock, and indeed there are some 
similarities, like the fact that MCS also uses atomic_exchange(), named 
"swap" in the paper: http://www.cise.ufl.edu/tr/DOC/REP-1992-71.pdf
But notice that the node of MCS uses a "locked" field which our lock 
does not have. Our MPSC lock has a single member on the node which is 
the "next" field. Moreover, in MCS, the unlock() function is lock-free 
because it does a compare-and-swap in a loop, while the unlock() in MPSC 
is wait-free because it does a single atomic_store()."
--


This PH.D doctor don't seem understand something important
from what i have read, read carefully what they have wrote here:

"But notice that the node of MCS uses a "locked" field which our lock 
does not have. Our MPSC lock has a single member on the node which is 
the "next" field."



Have you noticed with me or not ? they don't seem to understand
that the "locked" field of the MCS lock allow the MCS lock
to minimize efficiently the cache-coherence traffic, so it allows the 
MCS lock to minimize efficiently the contention and since it minimizes 
efficiently the cache-coherence traffic that means also it affects less 
the speed of the other threads , hence this will allow
the MCS lock to scale, and that's not the case with there
new lock , there new lock doesn't scale at all, and i have just
explain to you why in my previous post.


Thank you,
Amine Moulay Ramdane.

Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread

Thread

This PH.D doctor don't seem understand aminer <aminer@toto.net> - 2014-05-11 19:13 -0700

csiph-web