Hello,
I have thought more about my scalable RWLock , i mean my second
variation that scales and that is not FIFO fair and starvation free on
the reader side, if you use the Windows manual event object and call the
Setevent() and Resetevent() methods it will not be starvation free, so
i will not use the Windows manual event object, so i have to implement
this Setevent() and Resetevent methods inside my SemaMonitor and
SemaCondvar objects so that my scalable RWLock be FIFO fair , but i have
thought more and if you let my RWLock algorithm as it is, it will not be
starvation free cause i am looping back inside my scalable RWLock and
entering again my SemaMonitor but even if my SemaMonitor is FIFO fair my
RWLock will not be FIFO fair cause i am looping back and
entering again my SemaMonitor, so the solution is that i have to change
the following code:
if (FCount3^.fcount3 = 0)
then break
else
begin
LockedExchangeAdd(FCount1^[myid].fcount1,-1);
end;
with:
if (FCount3^.fcount3 = 0)
then break
So i have to not decrement and looping back.
Look here at my LW_RWLOCK algorithm:
http://pages.videotron.com/aminer/rwlock1.html
But with this change in my code my scalable RWLock algorithm will favor
more the reader threads than the writer threads, but it will be FIFO
fair and starvation free and this variation of my scalable RWLOCK will
support the all following requirements:
1- it will use my new SemaMonitor on both the reader and writer side
so it will use less CPU ressources.
2- It will scale on multicores
3- It will be FIFO fair on both the reader and the writer side
so it will be starvation free.
So i will ugrade soon my SemaMonitor and my SemaCondvar
and my scalable RWLock to support all those requirements.
Thank you,
Amine Moulay Ramdane.