- My explanation... - 1 Update
- cmsg cancel <n0630b$nio$1@dont-email.me> - 5 Updates
- Becareful of this algorithm - 1 Update
- About my new updated algorithm - 1 Update
- About my new scalable distributed reader-writer mutex... - 1 Update
- Scalable Distributed Reader-Writer Mutex version 1.3 is here... - 1 Update
| Ramine <ramine@1.1>: Oct 20 07:51PM -0700 Hello, As you have noticed i have wrote my new algorithm versoin 1.31 of my scalable distributed reader-writer mutex, and just after that i have made it sequential consistent, but you have to understand ladies and gentlemen that i have implemented my new algorithm in Object Pascal and i have ported it to FreePascal and Delphi, and they both (Delphi and FreePascal compilers) respect the strong memory model of the x86 architecture, so it was much easier for me to make it sequential consistent because you have only to take care of the following non-guarantee listed in the x86 spec: Loads may be reordered with older stores to different locations. So i have made my new algorithm version 1.31 of my scalable distributed reader-writer mutex sequential consistent with easy. That's not the case for C++, C++ have made it difficult for sequential consistency, because it respect the weak memory model that is much difficult to reason about and that is prone to mistakes by programmers, so becareful of C++ and languages that respect the weak memory model. And also my new algorithm of a scalable reader-writer mutex version 1.31 take care of false-sharing and it is now sequential consistent and like in Seqlock or RCU , my new scalable distributed reader-writer mutex doesn't use any atomic operations and/or StoreLoad style memory barriers on the reader side, so it's very fast and scalable..but you have to use the define's option TLW_RWLockX or the define's option TRWLockX inside the defines1.inc file for that. You can download it from here: https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex Thank you, Amine Moulay Ramdane. |
| bleachbot <bleachbot@httrack.com>: Oct 20 09:02PM +0200 |
| bleachbot <bleachbot@httrack.com>: Oct 20 09:21PM +0200 |
| bleachbot <bleachbot@httrack.com>: Oct 21 12:35AM +0200 |
| bleachbot <bleachbot@httrack.com>: Oct 21 01:19AM +0200 |
| bleachbot <bleachbot@httrack.com>: Oct 21 01:48AM +0200 |
| Ramine <ramine@1.1>: Oct 20 07:21PM -0700 Hello, I have just read about avout this Asymetric Read Writer lock... Please look at it here: https://github.com/chaelim/RWLock/blob/master/Src/RWLock.cpp You will notice that he is doing a stupid thing , look at the C header here: https://github.com/chaelim/RWLock/blob/master/Src/RWLock.h He is allocating an array of uint8_t, that means of type of 8 bits, like this in C: uint8_t m_readers[MAX_RWLOCK_READER_COUNT]; And after that in his algorithm he is doing in the CRWLock::EnterRead() this: m_readers[t_curThreadIndex] = true; and he is doing in CRWLock::LeaveRead() this: m_readers[t_curThreadIndex] = false; But this is stupid, because his array must be alligned on 64 bytes and every element in his array must be of a size of a cacheline to avoid false sharing. I have taking care of that on my new algorithm of a scalable reader-writer mutex the above problem of false sharing, and that is sequential consistent and like in Seqlock or RCU , my new scalable distributed reader-writer mutex doesn't use any atomic operations and/or StoreLoad style memory barriers on the reader side, so it's very fast and scalable..but you have to use the define's option TLW_RWLockX or the define's option TRWLockX inside the defines1.inc file for that. So be happy with my new algorithm that you can download from here: https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Oct 20 06:36PM -0700 Hello, We have to be careful with sequential consistency... I have just updated my new algorithm of new scalable distributed Reader-Writer mutex to version 1.31 and i have made it sequential consistent.. and now i think that all is correct... Also, like Seqlock or RCU , version2 of my new scalable distributed reader-writer mutex doesn't use any atomic operations and/or StoreLoad style memory barriers on the reader side, so it's very fast and scalable..but you have to use the define's option TLW_RWLockX or the define's option TRWLockX inside the defines1.inc file for that. You can download my new updated Scalable Distributed Reader-Writer mutex 1.31 from: https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Oct 20 03:22PM -0700 Hello, Like Seqlock or RCU , version2 of my new scalable distributed reader-writer mutex doesn't use any atomic operations and/or StoreLoad style memory barriers on the reader side, so it's very fast and scalable..but you have to use the define's option TLW_RWLockX or the define's option TRWLockX inside the defines1.inc file for that. You can download the source code of my new scalable distributed reader-writer mutex from: https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Oct 20 03:03PM -0700 Hello, Scalable Distributed Reader-Writer Mutex version 1.3 is here... Now version2 of my distributed reader-writer mutex doesn't use any atomic operations and/or StoreLoad style memory barriers on the reader side, so it's very fast.. Author: Amine Moulay Ramdane, based on Dmitry Vyukov C++ Reader-Writer Mutex Description: A scalable Distributed Reader-Writer Mutex based on the Dmitry Vyukov C++ Reader-Writer Mutex. This scalable Distributed Reader-Writer Mutex works accross processes and threads. There is two options to choose from, you can choose to use RWLock by uncommenting the define`s option called "TRWLock" inside the file called defines1.inc , or you can choose to use RWLockX by uncommenting the define`s option called "TRWLockX" inside the file called defines1.inc , if you set it to RWLock , it will spin-wait, but if you set it to RWLockX it will not spin-wait , but it will wait on the Event objects and my SemaMonitor. To compile it for MacOSX or Linux, please uncomment the define's option called "threads" inside the file called defines1.inc, but to use it accross processes and threads under windows , please comment the define's option called "threads"... And to use version1 of this scalable distributed RWLock uncomment the define's option version1 and comment the define's option version2 and to use version2 that is much more faster and scalable, uncomment the define's option version2 and comment the define's option version1. There is no limitation on version1. But on version2 you are limited to 1000 threads and you have to start once and for all your threads and work with all your threads, don't start every time a thread and exit from the thread.. Version2 of my distributed reader-writer mutex doesn't use any atomic operations and/or StoreLoad style memory barriers on the reader side, so it's very fast, but you have to use the define's option TLW_RWLockX or the define's option TRWLockX inside the defines1.inc file for that. You can download my Scalable Distributed Reader-Rriter Mutex from: https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex Language: FPC Pascal v2.2.0+ / Delphi 7+: http://www.freepascal.org/ Operating Systems: Windows, Mac OSX , Linux... Required FPC switches: -O3 -Sd -dFPC -dFreePascal -Sd for delphi mode.... Required Delphi switches: -$H+ -DDelphi {$DEFINE CPU32} and {$DEFINE Windows32} for 32 bit systems {$DEFINE CPU64} and {$DEFINE Windows64} for 64 bit systems 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