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

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

About memory models...

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

Contents

  About memory models... Horizon68 <horizon@horizon.com> - 2019-02-01 13:36 -0800

#4919 — About memory models...

Hello..


About memory models...

I wrote about memory models, and i think that
Delphi and FreePascal had the necessary to make it
easier even if they have no memory model, here
is the functions that you need:

For Delphi there is a function called System.MemoryBarrier
and here it is:

http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.MemoryBarrier


And for FreePascal there three functions called:

- ReadWriteBarrier
- WriteBarrier
- ReadBarrier

Here they are:

https://www.freepascal.org/docs-html/rtl/system/readwritebarrier.html


So as you have noticed my scalable algorithms works on x86 ,
but with the above functions i will make them more easily portable
to ARM and to other CPU architetures.

And 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 in C++ and Delphi and Freepascal.




Thank youm
Amine Moulay Ramdane.

[toc] | [standalone]

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

csiph-web