| comp.programming.threads@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
- About my new algorithm - 2 Updates
- About sequential consistency - 1 Update
- Sequential consistency of my scalable distributed sequential lock - 1 Update
| Ramine <ramine@1.1>: Dec 04 07:57PM -0800 Hello, Chriss M. Thomasson wrote about my new algorithm: >RMR and associated nasty memory barrier simply destroys >performance when compared to RCU read-side overhead. >I am not sure that you actually understand RCU fully. Chriss M Thomasson, i think you don't understand correclty my new algorithm , cause this "lock add" inside the RLock() of the reader side is run only by the group of threads belonging to the same core, cause RLock() called from the reader side belong to a distributed algorithm, so it's very very cheap, it is why my new algorithm scales very well. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Dec 04 08:07PM -0800 Look inside the source code, RLock() called from the reader side belong to the DRWLOCK library that is a distributed reader-writer mutex, this is why it's very very cheap and this is why it scales very very well... Please look inside my algorithm's source code again to understand it better by downloading it from: https://sites.google.com/site/aminer68/scalable-distributed-sequential-lock Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Dec 04 04:58PM -0800 Hello... About the sequential consistency 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. |
| Ramine <ramine@1.1>: Dec 04 04:57PM -0800 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. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
No comments:
Post a Comment