Re: rmlock question..

Julian Elischer 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.
>> 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.
Yes
>
>
> so the quick answer is:
> "request order is partially preserved, enough to ensure that lockout 
> does not occur."
>
Yes, the answer catches the spirit of the issue.
This being said high priority writers could indefinitely block access to 
low priority readers.
( But then you really should not be using rmlocks)

Stephan