I've looked at DRWLOCK.PAS and it looks exactly the same as; http://www.1024cores.net/home/lock-free-algorithms/reader-writer-problem/distributed-reader-writer-mutex What is novel there?
On Thu, Feb 5, 2015 at 8:36 PM, Amine Moulay Ramdane <amine...@gmail.com> wrote: > > Dmitry Vyukov wrote: >>I don't see any explanation regarding difference between DSLOCK.ZIP >>and DSLOCK_XE.ZIP. >>I can't download both files, the server says "The requested URL was >>not found on this server". > > > To download the zip file , please click on the small arrow that you will > find just on the right of the name of DSLock.zip. > > > > > Thank you, > Amine Moulay Ramdane. > > > > > > On Friday, January 30, 2015 at 1:38:50 PM UTC-8, Amine Moulay Ramdane wrote: >> >> Hello, >> >> >> I want to clear something about my Distributed sequential lock algorithm, >> you can download it and read about it here: >> >> >> https://sites.google.com/site/aminer68/scalable-distributed-sequential-lock >> >> >> If you read carefully the source code you will noticed that i am using >> this: "myid3:=FCount6^.fcount6;" inside the RLock() >> method in the reader side, so when my algorithms switches from a Seqlock >> mode to a Distributed lock mode, the >> "myid3:=FCount6^.fcount6;" will be "serialized" when the writer side >> increment FCount6^.fcount6, so in the writer side i am calling the >> distributed reader-writer lock when the algorithm swithes to a Distributed >> mode, so if you have noticed since the "myid3:=FCount6^.fcount6;" is >> serialized in the reader side when "FCount6^.fcount6" is incremented in the >> writer side, >> so this will look like a probalistic mechanism cause the reader side is >> serializing the the transfer of FCount6^.fcount6 >> on the bus, and the writer side is serializing the transfer of a variable >> in the bus also when it is calling the WLock() of the >> distributed lock, so this is a kind of a probalistic mechanism cause this >> can generate contention and the reader side can call >> RLock() on a distributed lock's reader-writer mutex that is entered >> before the reader by the writer, but even though it is a probalistic >> mechanism, this probabilistic mechanism will give a good result and it >> eliminates the "livelock" situation of the Seqlock when there is more >> writers. >> >> >> >> >> Thank you for your time. >> >> >> Amine Moulay Ramdane. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "Scalable Synchronization Algorithms" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to lock-free+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/lock-free/0238f2ea-068c-4c33-b2ad-a8b9d95ba36c%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Dmitry Vyukov All about lockfree/waitfree algorithms, multicore, scalability, parallel computing and related topics: http://www.1024cores.net -- --- You received this message because you are subscribed to the Google Groups "Scalable Synchronization Algorithms" group. To unsubscribe from this group and stop receiving emails from it, send an email to lock-free+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/lock-free/CAEeQi3tavuWa6BK0KFbMZ-rcLdnTFfgWSZjB%3DJfn86HWYQsDGg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
