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

Groups > comp.programming.threads > #2323

I have just read this today

Cross-posted to 2 groups.

Show all headers | View raw

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


In 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.


You can download my scalable AMLock from:


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



Thank you,
Amine Moulay Ramdane.

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

Thread

I have just read this today aminer <aminer@toto.net> - 2014-05-11 18:51 -0700

csiph-web