Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

About memory models...

8 views
Skip to first unread message

Horizon68

unread,
Feb 1, 2019, 4:38:38 PM2/1/19
to
Hello...

Read this:


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.


0 new messages