Hello all,
Please read this about the Windows event object:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682655(v=vs.85).aspx
It says: "Do not assume a first-in, first-out (FIFO) order"
So i have thought more about this, and if you have noticed i have
designed and implemented two variations of my scalable RWLock, one that
is called LW_RWLOCK that scales and that is not starvation free and that
uses more CPU ressources, and another one that is called RWLock that
scales and that is not stavation free on the reader side and that uses
less CPU ressources, so i have thought more about the second one that is
called RWLock that uses my SemMonitor on the writer side and that uses a
portable event object on the reader side, and i think it is not
starvation free on the reader side cause the Windows event object that i
am using on the reader side of my scalable RWLock is not FIFO fair, so i
have thought more about this and i think that i have to upgrade my
SemaMonitor to support the set() and reset() methos as in the Windows
event object but my SemaMonitor will be FIFO fair so
it will be starvation free , the windows event object is not,
after that i will enhanced and upgrade my new SemaMonitor on the reader
side of my
scalable RWLock so that it supports many requirements such us:
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 soon upgrade my SemaCondVar and SemaMonitor and my scalable
RWLock so stay tuned.
Thank you,
Amine Moulay Ramdane.