must be significant, on the order of, let's say, 10'000 cycles. And the
more hardware threads you have the longer the time must be. Otherwise,
inter-reader synchronization overheads dominate, and the system does not scale." Read here: http://www.1024cores.net/home/lock-free-algorithms/reader-writer-problem/distributed-reader-writer-mutex I have done some tests with my light weight MREW and my lockfree mpmc fifo queue and what i think is that the CAS is generating a lot of
contention this is is why my rwlock is not scaling. What you are doing Dmitry Vyukovin in your distributed
rwlock is lowering the contention using the same method as lock striping it is why it is scaling, but there
is still a possibility of contention that can cause a problem to the scalability if you are not
setting the number of rwlocks inside your distributed rwlock correctly. other than that: I have looked at the Distributed Reader-Writer Mutex by Dmitry Vyukov, look
at it here:"
i think there is a problem with this method, cause look at the write
for (i = 0; i !=
mtx->proc_count; i += 1)
What is wrong with it ? suppose two or more writers want to
distributed rwlock there is a possibility of a deadlock.
i think you have to use a critical section around the for loop to be able
lock all the rwlocks atomically to avoid the deadlock