julian at elischer.org
Mon Nov 26 10:34:05 PST 2007
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
> 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."
> (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
More information about the freebsd-current