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


Groups > comp.programming.threads > #2729 > unrolled thread

Sequential consistency of my scalable distributed sequential lock

Started byRamine <ramine@1.1>
First post2014-12-04 16:57 -0800
Last post2014-12-04 16:57 -0800
Articles 1 — 1 participant

Back to article view | Back to comp.programming.threads


Contents

  Sequential consistency of my scalable distributed sequential lock Ramine <ramine@1.1> - 2014-12-04 16:57 -0800

#2729 — Sequential consistency of my scalable distributed sequential lock

FromRamine <ramine@1.1>
Date2014-12-04 16:57 -0800
SubjectSequential consistency of my scalable distributed sequential lock
Message-ID<m5qlak$lf0$2@dont-email.me>
Hello,


About the sequential consystency of  my scalable distributed sequential 
lock, my algorithm works on x86 architecture and i think my algorithm is 
correct cause look at the source code of the WLock() method, since i am 
using a Ticket spinlock with a proportional backoff on the writer side, 
the Ticket spinlock is using a "lock add" assembler instruction to 
increment a counter in the Enter() method of the ticket spinlock , and 
this "lock add" assembler instruction is a barrier for stores and loads 
on x86, so the WLock() method is sequential consistent and correct, now 
look at the WUnlock() , we don't need an "sfence" cause stores are not 
reordered  with stores on x86 , so WUnlock() method is sequential 
consistent and correct, now look at the RLock() method, since i am using 
a "lock add" assembler instruction inside the call to the RLock() of the 
distributed reader-writer lock , so it acts as a barrier and loads and 
stores inside the reader section are not reordered with this barrier on 
x86, so RLock() is sequential consistent and correct, and for RUnlock() 
since i am calling RUnlock() of the distributed reader-writer mutex , 
this RUnlock() is calling "lock add" in assembler, so it acts as a 
barrier so the the loads and stores that we are using after this barrier 
are not reordrered with this barrier, so all in all my algorithm is 
sequential consistent and correct on x86. So be confident cause i have 
reasoned correctly and i think my algorithm is correct and it is a 
powerful synchronization mechanism that can replace RCU and that can 
replace Seqlock cause it beats Seqlock.

Disclaimer:

My software is provided on an "as-is" basis, with no warranties,
express or implied.  The entire risk and liability of using it is yours. 
Any damages resulting from the use or misuse of this software will be 
the responsibility of the user.


You can download my scalable distributed sequential lock version 1.01 from:

https://sites.google.com/site/aminer68/scalable-distributed-sequential-lock





Thank you,
Amine Moulay Ramdane.






[toc] | [standalone]


Back to top | Article view | comp.programming.threads


csiph-web