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


Groups > comp.programming.threads > #3532

C++ synchronization objects library

From Ramine <toto@toto.net>
Newsgroups comp.programming.threads
Subject C++ synchronization objects library
Date 2016-12-14 09:58 -0800
Organization A noiseless patient Spider
Message-ID <o2s156$uep$10@dont-email.me> (permalink)

Show all headers | View raw


Hello....


C++ synchronization objects library


Author: Amine Moulay Ramdane

Email: aminer@videotron.ca

Description:

This library contains 9 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, and eight is my LW_Asym_RWLockX that is a 
lightweight scalable Asymmetric Reader-Writer Mutex that uses a technic 
that looks like Seqlock without looping on the reader side
like Seqlock, and this has permited the reader side to be costless,
it is FIFO fair on the writer side and FIFO fair on the reader side and
it is of course Starvation-free and it does spin-wait,  and nine is my 
Asym_RWLockX, a lightweight scalable Asymmetric Reader-Writer Mutex that 
uses a technic that looks like Seqlock without looping
on the reader side like Seqlock, and this has permited the reader
side to be costless, it is FIFO fair on the writer side and FIFO fair on 
the reader side and it is of course Starvation-free and it does not
spin-wait, but waits on my SemaMonitor, so it is energy efficient.

My scalable Asymmetric Reader-Writer Mutex calls the windows 
FlushProcessWriteBuffers() just one time, but my scalable
Asymmetric  Distributed Reader-Writer Mutex calls 
FlushProcessWriteBuffers() many times.


You can download it from:

https://sites.google.com/site/aminer68/c-synchronization-objects-library


I have implemented my inventions with FreePascal and Delphi compilers 
that don't reorder loads and stores even with compiler optimization, and 
this is less error prone than C++ that follows a relaxed memory model 
when compiled with optimization, so i have finally compiled my 
algorithms implementations with FreePascal into Dynamic Link Libraries 
that are used by C++ in a form of my  C++ Object Synchronization Library.

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{
  SemaMonitor(bool state, long1 InitialCount1=0,long1 
MaximumCount1=INFINITE);
  ~SemaMonitor();

void wait(signed long  mstime=INFINITE);
void signal();
void signal_all();
void signal(long1 nbr);
void setSignal();
void resetSignal();
long2 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..

Here is my new invention that is my new algorithm:

I have invented a new algorithm of my scalable Asymmetric Distributed 
Reader-Writer Mutex, and this one is costless on the reader side, this 
one doesn't use any atomic operations and/or StoreLoad style memory 
barriers on the reader side, my new algorithm has
added a technic that looks like Seqlock, but this technic doesn't
loop as Seqlock. Here is my algorithm:

On the reader side we have this:

-- 
procedure TRWLOCK.RLock(var myid:integer);

var myid1:integer;
    id:long;
begin


  myid1:=0;
id:=FCount5^.fcount5;
if (id mod 2)=0
then FCount1^[myid1].fcount1:=1
else FCount1^[myid1].fcount1:=2;
if ((FCount3^.fcount3=0) and (id=FCount5^.fcount5) and 
(FCount1^[myid1].fcount1=1))
then
else
begin
  LockedExchangeAdd(nbr^.nbr,1);
  if FCount1^[myid1].fcount1=2
  then LockedExchangeAdd(FCount1^[myid1].fcount1,-2)
   else if FCount1^[myid1].fcount1=1
   then LockedExchangeAdd(FCount1^[myid1].fcount1,-1);
   event2.wait;
   LockedExchangeAdd(FCount1^[myid1].fcount1,1);
   LockedExchangeAdd(nbr^.nbr,-1);
  end;
end;
-- 

The writer side will increment FCount5^.fcount5 like does
a Seqlock, and the reader side will grap a copy of FCount5^.fcount5
and copy it on the id variable, if (id modula 2) is equal to zero
that means the writer side has not modified yet Fcount3^.fcount3,
and the reader side will test again if FCount3^.fcount3 equal 0, and
if id=FCount5^.fcount5 didn't change and if FCount1^[myid1].fcount1 that 
we have assigned before didn't change and that means that we are sure 
that the writer side will block on FCount1^[myid1].fcount1 equal 1.

And notice with me that i am not looping like in Seqlock.

And the rest of my algorithm is easy to understand.

This technic that looks like Seqlock without looping like Seqlock
will allow us to be sure that although the x86 architecture will reorder 
the loads of the inside reader critical section , the loads
inside the reader critical section will not go beyond the load of 
FCount5^.fcount5 and this will allow my algorithm to work correctly.

My algorithm is FIFO fair on the writer side and FIFO fair on the
Reader side , and of course it is Starvation-free, and it is
suitable for realtime critical systems.

My Asym_RWLockX and LW_Asym_RWLockX algorithms work the same.

You will find the source code of my new algorithm here:

https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex

It is the version 2 that is my own algorithm.

and you can download the source code of my Asym_RWLockX and 
LW_Asym_RWLockX algorithms that work the same from here:

https://sites.google.com/site/aminer68/scalable-rwlock

Language: GNU C++ and Visual C++ and C++Builder

Operating Systems: Windows, Linux, Unix and Mac OS X on (x86)



Thank you,
Amine Moulay Ramdane.


Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread


Thread

C++ synchronization objects library Ramine <toto@toto.net> - 2016-12-14 09:58 -0800

csiph-web