Re: rmlock question..

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.
> Writers always acquire an internal mutex, disallow further readers to 
> acquire the lock
> using the read lock fastpath and then wait until all current readers 
> unlock the lock.
> ( During this wait priority is propagated from the writer to one reader 
> at a time)
> The writer unlocks the rmlock by unlocking the internal  mutex.
> If the reader fastpath is disabled , a reader acquires the internal 
> mutex, grants itself the
> lock, enabled the reader fastpath and unlocks the internal mutex. (1)
> This means that on a contested rmlock the mutex locking order mainly 
> influences
> the rmlock locking order.
> The internal mutex locking order is mainly dictated by the priority of 
> the locking threads.
> However FreeBSD uses adaptive mutexes by default and the locking order 
> of multiple
> threads spinning to acquire a mutex is undefined.
> 
> 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.

Thankyou. That was the information I was looking for.
I assume then that the order that the 
order that the remainign threads contest the lock is:
R5, R3, W2, R4

then that the cycle repeats and W2 will wait for R5 and R3,
and R4 will wait for W2.


so the quick answer is:
 "request order is partially preserved, enough to ensure that lockout does not occur."



> 
> 
> Stephan
> 
> 
> (1) - Unless recursive read locks enabled and a current readers 
> recursively locks it a second time.
>    In that case the lock is (re)-granted without acquiring the internal 
> mutex first
>