Re: rmlock question..

From: Stephan Uphoff <ups_at_freebsd.org>
Date: Mon, 26 Nov 2007 10:26:38 -0500
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.


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
Received on Mon Nov 26 2007 - 14:53:00 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:23 UTC