I have just read this today

[aminer]

Hello,

I have just read this today:

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

They have invented a new lock , but you have to be carefull
cause look at the source code:

https://github.com/pramalhe/ConcurrencyFreaks/blob/master/C11/locks/mpsc_mutex.c

Inside the mpsc_mutex_lock() function they are doing this:


while (lhead != prev) {
sched_yield();
lhead = atomic_load(&self->head);
}


But this is not scalable cause "&self->head" is mutating
every time the mpsc_mutex_unlock() function is doing this:

mpsc_mutex_node_t * mynode = atomic_load_explicit(&prev->next,
memory_order_relaxed);


And this will cause too much cache-coherence traffic when
it will be run on more cores , and too much cache-coherence traffic
means contention and means slow execution, so there new lock is not
scalable at all, so becarefull.

And you have to be carefull with the Ticket Spinlock with a proportional
backoff also, cause a sched_yield() or sleep(0) is mandatory with it...

And i have done some benchmarks and i have found that
my scalable array based lock called AMLock is faster than
node based locks such us CLH or MCS, and it is even faster
than Ticket Spinlock with a proportional backoff.

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 PHd 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 allows 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.


You can download my scalable AMLock from:


https://sites.google.com/site/aminer68/scalable-amlock



Thank you,
Amine Moulay Ramdane.