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


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

I have just taken a look at the following algorithm invented by ,Dmitry Vyukov

Started byHorizon68 <horizon@horizon.com>
First post2019-02-01 12:40 -0800
Last post2019-02-01 12:40 -0800
Articles 1 — 1 participant

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


Contents

  I have just taken a look at the following algorithm invented by ,Dmitry Vyukov Horizon68 <horizon@horizon.com> - 2019-02-01 12:40 -0800

#4918 — I have just taken a look at the following algorithm invented by ,Dmitry Vyukov

FromHorizon68 <horizon@horizon.com>
Date2019-02-01 12:40 -0800
SubjectI have just taken a look at the following algorithm invented by ,Dmitry Vyukov
Message-ID<q32as4$7ip$7@dont-email.me>
Hello..

I have just taken a look at the following algorithm invented by
Dmitry Vyukov:

https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc


Notice that it is using FlushProcessWriteBuffers() , and notice on the 
following what said Chris Thomasson about FlushProcessWriteBuffers()

==

Well, the thing with FlushProcessWriteBuffers() is that it will generate 
a lot of traffic in the sense of sending the interrupts to all the CPUS 
in the processes affinity mask. This is an "active" form of quiescent 
state auto-detection. As of now, vZOOM uses "passive" detection 
technique on Windows; It does not need to interrupt CPU activity.

AFAICT, that is the only advantage I can see to passive epoch detection,
rather than active. Also, for PDR, the epochs should be detected on a
frequent enough basis to keep the deferred object lists from backing up 
too much. The frequency of epochs in an active system will be creating a 
lot of IPI traffic, while the passive system will be creating none.

Read more here:

https://groups.google.com/forum/#!topic/comp.programming.threads/E0gGTkg46HE
==


But I i have just invented a new scalable RWLock algorithm that is
"better" than the above because it doesn't need 
FlushProcessWriteBuffers() and it doesn't use any membar or lock in the 
readers side and it is starvation-free and it is FIFO fair on the 
readers side and FIFO fair on the writers side, and i will implement my 
new scalable algorithm on C++ and Delphi and Freepascal.




Thank youm
Amine Moulay Ramdane.

[toc] | [standalone]


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


csiph-web