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 firstReceived 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