Monday, May 9, 2016

Digest for comp.lang.c++@googlegroups.com - 10 updates in 6 topics

bleachbot <bleachbot@httrack.com>: May 09 08:58PM +0200

bleachbot <bleachbot@httrack.com>: May 09 10:05PM +0200

bleachbot <bleachbot@httrack.com>: May 10 12:08AM +0200

bleachbot <bleachbot@httrack.com>: May 10 12:13AM +0200

Ramine <ramine@1.1>: May 09 06:18PM -0700

Hello,
 
 
Here another confirmation from Remy Lebeau (TeamB) that i received:
 
https://forums.embarcadero.com/thread.jspa?threadID=211097&tstart=0
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 09 06:13PM -0700

Hello....
 
I have talked about my first security wall, that
is in Delphi and FreePascal that values of dynamic allocated
pointers are not put in registers, so in my algorithms
of my C++ synchronization objects library i am using
dynamic allocated pointers.
 
Here is my second security wall:
 
Since i am using, in C++, Dynamic Link Libraries compiled with
Freepascal , i think my C++ synchronization objects library is
safe because C++ can not optimize from outside and put
variables of the Dynamic Link Libraries in registers.
 
So i think that you can be confident with my C++ synchronization
objects library.
 
So you can download my new and extended C++ synchronization objects
library from, i think that it is safe now:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 09 04:06PM -0700

Hello.......
 
 
We have to reason like an expert...
 
Since C++ can use registers to store variable, so
without memory barrier you can not be sure that
the variables on the registers will be flushed to
memory and made visible immediatly by the
cache-coherence protocol, so in C++ this is
a difficult situation, but since i am using
Delphi compiler and FreePascal compilers, i am safe,
because i am using dynamically allocated pointers,
and dynamically allocated pointers in FreePascal
and Delphi allow us to prevent the Delphi and FreePascal
compilers from using a register for the values of
dynamically allocated memory, but it still can use registers
for the addresses of the pointers, but this allow us to be safe
in Delphi an FreePascal compiler.
 
Other than that since i am not using memory barriers
or fences on the reader side, so in my algorithm
i have on the RLock() method this:
 
FCount1^[myid1].fcount1:=FCount1^[myid1].fcount1+1;
 
 
And on the RUnlock() method i have this:
 
FCount1^[myid1].fcount1:=0;
 
 
So in x86 since stores can not be reorder with otherther
loads and stores to the same location.
 
So i can state that finally my implementation of
my algorithm is safe and it does not need
the windows function FlushProcessWriteBuffers().
 
 
So you can download my new amd extended C++ synchronization objects
library from, i think that it is safe now:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 09 02:58PM -0700

Hello....
 
I think i have to use the windows FlushProcessWriteBuffers on
my asymmetric Distributed reader-writer mutex, because
the memory barriers ensure all the processor cache are flushed
to RAM, but since i am not using memory barriers or any atomics,
so i must use the windows FlushProcessWriteBuffers. i am currently
correcting this bug , and i will post soon an updated version.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 08 09:20PM -0700

Hello.....
 
 
A new scalable synchronization algorithm is coming...
 
I was thinking more and more, and i have come to a conclusion that
Seqlock or my SeqlockX are not suitable for realtime critical systems,
because they are lockfree, so prone to starvation.
 
So i am right now finishing a new algorithm and implementing it
in Object Pascal and C++, this new algorithm is a scalable reader-writer
mutex that is costless on the reader side, as is RCU, and in the writer
side it is uses a distributed technic as the distributed reader-writer
mutex, this algorithm is FIFO fair on the writer side and FIFO fair on
the reader side and it is of course starvation-free, so it is
suitable for realtime critical systems, the simplicity of use by users
of the implementation of this algorithm makes it more suitable that the
much harder approach of RCU.
 
 
So stay tuned , my new algorithm and its implementation in C++ and
Object pascal is coming soon...
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 08 09:39PM -0700

Hello...
 
Look at this Asymmetric rw_mutex with atomic-free fast-path for readers
by Dmitry Vyukov:
 
https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc
 
 
My new algorithm and its implementation that is coming soon
doesn't use epoch detection logic, an it uses a distributed
technic, and it will be suitable for realtime critical systems,
and the simplicity of use by users of the implementation of this
algorithm makes it more suitable that the much harder approach of RCU.
 
 
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.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)