Tuesday, May 10, 2016

Digest for comp.programming.threads@googlegroups.com - 20 updates in 9 topics

bleachbot <bleachbot@httrack.com>: May 09 06:26PM +0200

bleachbot <bleachbot@httrack.com>: May 09 06:35PM +0200

bleachbot <bleachbot@httrack.com>: May 09 06:41PM +0200

bleachbot <bleachbot@httrack.com>: May 09 07:33PM +0200

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

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

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

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

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

bleachbot <bleachbot@httrack.com>: May 10 01:40AM +0200

Ramine <ramine@1.1>: May 09 07:44PM -0700

Hello..
 
I have just read this from Martin Thompson:
 
"Firstly, our compilers can generate programs that store variables in
registers for relatively long periods of time for performance reasons,
e.g. variables used repeatedly within a loop. If we need these
variables to be visible across cores then the updates must not be
register allocated. This is achieved in C by qualifying a variable as
"volatile". Beware that C/C++ volatile is inadequate for telling the
compiler to order other instructions. For this you need fences/barriers."
 
read more here:
 
https://dzone.com/articles/cpu-cache-flushing-fallacy
 
 
So i think that a necessary and sufficient condition so that
the variable be visible accross cores is to qualify
a variable as "volatile".
 
So i don't think that Dmitry Vyukov is right to add the windows function
called FlushProcessWriteBuffers() when he wrote this:
 
https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc
 
 
I don't think this algorithm of Dmitry Vyukov needs
FlushProcessWriteBuffers(), because it already has declared the
necessary variable as "volatile".
 
 
Thank you,
Amine Moulay Ramdane.
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:12PM -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:05PM -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:57PM -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 09 02:17PM -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 scalable Asymmetric Distributed Reader-Writer Mutex and its
implementation doesn't use epoch detection logic, and it doesn't use any
atomic operations and/or StoreLoad style memory barriers on the reader
side,and it uses a distributed technic, and it 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, and
the simplicity of use by users of the implementation of this my
new algorithm makes it more suitable that the much harder approach of RCU.
 
You can download my new and extended C++ synchronization objects library
from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 09 12:35PM -0700

Hello....
 
 
My new algorithm that looks like RCU is here, it doesn't use
any atomic operations and/or StoreLoad style memory barriers
on the reader side, and it is finally implemented, you can download it
from here:
 
https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex
 
 
It is not the version 1 based on Dmitry Vyukov ,
but it is the version 2 that is own algorithm,
look at my version 2 algorithm implementation inside
DRWLOCK.pas source code.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 09 12:41PM -0700

On 5/9/2016 12:35 PM, Ramine wrote:
 
> https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex
 
> It is not the version 1 based on Dmitry Vyukov ,
> but it is the version 2 that is own algorithm,
 
I mean: but it is the version 2 that is my own algorithm.
 
 
Ramine <ramine@1.1>: May 09 01:34PM -0700

Hello,
 
To compile test1.pas example that uses my powerful Scalable Asymmetric
Distributed Reader-Writer Mutex, please uncomment define option
"version1" inside defines1.inc and comment the define option
"version2" inside defines1.inc
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 09 12:28PM -0700

Hello...
 
 
My C++ synchronization objects library was extended...
 
My new algorithm that looks like RCU is here, i have added
my scalable asymmetric DRWLock that doesn't use any atomic operations
and/or StoreLoad style memory barriers on the reader side, so it look
like RCU, and it is fast. This scalable Asymmetric Distributed
Reader-Writer Mutex is FIFO fair on the writer side and FIFO fair on the
reader side and of course it is starvation-free and it does spin-wait,
and i have addded my scalable asymmetric DRWLockX that doesn't use any
atomic operations and/or StoreLoad style memory barriers on the reader
side, so it look like RCU, and it is fast. This scalable Asymmetric
Distributed Reader-Writer Mutex is FIFO fair on the writer side and FIFO
fair on the reader side and of course it is starvation-free, and it does
not spin-wait, but it waits on Event objects and my
SemaMonitor, so it is energy efficient.
 
 
You can download my new and extended C++ synchronization objects library
from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
Author: Amine Moulay Ramdane
 
Email: aminer@videotron.ca
 
Description:
 
This library contains seven synchronization objects, first one is my
scalable SeqlockX that is a variant of Seqlock that eliminates the
weakness of Seqlock that is "livelock"of the readers when there is more
writers, and second is my scalable MLock that is a scalable
lock , and third is my SemaMonitor that combines all characteristics
of a semaphore and an eventcount and also a windows
Manual-reset event and also a windows Auto-reset event, and fourth
is my scalable DRWLock that is a scalable reader-writer lock that is
starvation-free and it does spin-wait, and five is is my scalable
DRWLockX that is a scalable reader-writer lock that is
starvation-free and it doesn't spin-wait, but it waits on the Event
objects and my SemaMonitor, so it is energy efficient, and six one is
my scalable asymmetric DRWLock that doesn't use any atomic operations
and/or StoreLoad style memory barriers on the reader side, so it look
like RCU, and it is fast. This scalable Asymmetric Distributed
Reader-Writer Mutex is FIFO fair on the writer side and FIFO fair on the
reader side and of course it is starvation-free and it does spin-wait,
and seven one is my scalable asymmetric DRWLockX that doesn't use any
atomic operations and/or StoreLoad style memory barriers on the reader
side, so it look like RCU, and it is fast. This scalable Asymmetric
Distributed Reader-Writer Mutex is FIFO fair on the writer side and FIFO
fair on the reader side and of course it is starvation-free, and it does
not spin-wait, but it waits on Event objects and my
SemaMonitor, so it is energy efficient.
 
If you take a look at the zip file , you will notice that it contains
the DLLs Object pascal source codes, to compile those dynamic link
libraries source codes you will have to download my SemaMonitor Object
pascal source code and my SeqlockX Object pascal source code and my
scalable MLock Object pascal source code and my scalable DRWLock Object
pascal source code from here:
 
https://sites.google.com/site/aminer68/
 
I have compiled and included the 32 bit and 64 bit windows Dynamic Link
libraries inside the zip file, if you want to compile the dynamic link
libraries for Unix and Linux and OSX on (x86) , please download the
source codes of my SemaMonitor and my scalable SeqlockX and my scalable
MLock and my scalable DRWLock and compile them yourself.
 
My SemaMonitor of my C++ synchronization objects library is
easy to use, it combines all characteristics of a semaphore and an
eventcount and also a windows Manual-reset event and also a windows
Auto-reset event, here is its C++ interface:
 
class SemaMonitor{
public:
SemaMonitor(bool state, long2 InitialCount1=0,long2
MaximumCount1=INFINITE);
~SemaMonitor();
 
void wait(unsigned long mstime=INFINITE);
void signal();
void signal_all();
void signal(long2 nbr);
void setSignal();
void resetSignal();
long1 WaitersBlocked();
};
 
So when you set the first parameter that is state of the constructor to
true. it will add the characteristic of a Semaphore to the to the
Eventcount, so the signal will not be lost if the threads are not
waiting for the SemaMonitor objects, but when you set the first
parameter of the construtor to false, it will not behave like a
Semaphore because if the threads are not waiting for the SemaCondvar or
SemaMonitor the signal will be lost..
 
the parameters InitialCount1 and MaximumCount1 is the semaphore
InitialCount and MaximumCount.
 
The wait() method is for the threads to wait on the SemaMonitor
object for the signal to be signaled.
 
and the signal() method will signal one time a waiting thread on the
SemaMonitor object.
 
the signal_all() method will signal all the waiting threads on the
SemaMonitor object.
 
the signal(long2 nbr) method will signal nbr number of waiting threads
 
the setSignal() and resetSignal() methods behave like the windows Event
object's methods that are setEvent() and resetEvent().
 
and WaitersBlocked() will return the number of waiting threads on
the SemaMonitor object.
 
As you have noticed my SemaMonitor is a powerful synchronization object.
 
Please read the readme files inside the zip file to know more about them..
 
Language: GNU C++ and Visual C++ and C++Builder
 
Operating Systems: Windows, Linux, Unix and OSX on (x86)
 
 
 
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.programming.threads+unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)