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


_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"