rmlock question..
Stephan Uphoff
ups at freebsd.org
Mon Nov 26 11:16:27 PST 2007
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
More information about the freebsd-current
mailing list