Re: rmlock question..

Darren Reed wrote:
> Stephan Uphoff wrote:
>> Julian Elischer wrote:
>>> Julian Elischer wrote:
>>>> If I make an exclusive rmlock request on an rmlock that has a busy 
>>>> set of readers coming and going, do new readers wait for me to get
>>>> my turn, or do I have to wait for a moment where there are no more 
>>>> readers before I get a go?
>>> in fact if the requests are of the order
>>>
>>> reader, reader, writer, reader, reader, writer, reader
>>>
>>> is the order of evaluation defined? is it preserved?
>> This is a bit of a tricky question to answer.
>> ...
>> So in your example the first writer (W1) will be blocked by the first 
>> two Readers (R1,R2)
>> but will disable the read fast path and hold the internal mutex.
>> W1 will block R3,R4,W2,R5 as they all need to acquire the internal 
>> mutex.
>> If R1,R2 release the lock, W1 will become unblocked and eventually 
>> unlock the lock
>> such releasing the mutex. At this time R3,R4,W2,R5 compete for the 
>> mutex and whoever
>> wins is next in the locking order.
>
Sorry for the delay in answering.
Somehow your post did not make it to my inbox.
> Is there is a chance that so long as there is more than one Reader
> waiting for a mutex, a Write lock request may never be granted?
No. Even if all reader waiting for the mutex have a higher priority and need
to acquire the mutex for a short time no new readers will need the mutex 
as long
as the readlock fastpath is enabled. The reader fastpath is only disabled
once the writer holds the mutex.

> Given the name "read mostly", is there any favouritism towards
> Readers vs Writers when competing for the mutex?
No the name is derived from the fact that the lock is designed to work 
mostly
in a state where the reader fastpath can be used.
Using the fastpath the shared lock can be acquired without any atomic 
operations or
dirtying of shared cache lines.

> Or conversely, if there is always a pending Write request that a
> read is never granted?
>
Yes - if there is always a write request and the write threads always
have better priority than the read request.
But then you really, really have picked the wrong lock.
( And you would have the same problem just using a mutex)
> When R3,R4,W3,R5 compete for the mutex, if R3-5 wins, is
> the read fast path enabled again?
>
I assume you mean R3, R4, W2, R5

Yes - however none of R3-5 will be retried using the fastpath.
( All need to acquire the mutex)
> If any of the Readers wins, does this mean that all Readers are
> dequeued, or only those upto the pending Write?
No - if a reader wins it enables the fastpath  - but currently blocked 
readers
are not on the fastpath and still need to acquire the internal mutex.
In this case R3, R4, will acquire the mutex for a short time.
Then W2 will acquire the internal mutex and wait for R3,R4 to release 
the read lock.
Once W2 release the write lock (and as such the internal mutex) R5 will be
unblocked and can acquire the internal mutex.
Actually it is not quite as deterministic as lock order on mutexes is not
that strictly enforced.
This may change in the future if I replace the internal rmlock
mutex with lower level primitives.
Right now rmlock is in a state where only the read fastpath is really 
optimized.
The rest is functional complete but I expect some tuning to happen once we
have more experience with situations where rmlocks are useful.

Stephan