Date: Mon, 26 Nov 2007 14:16:46 -0500 From: Stephan Uphoff <ups@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD Current <current@freebsd.org> Subject: Re: rmlock question.. Message-ID: <474B1B9E.2080703@freebsd.org> In-Reply-To: <474B1195.1020504@elischer.org> References: <4749BB5B.7040801@elischer.org> <4749BBDE.6000107@elischer.org> <474AE5AE.4020301@freebsd.org> <474B1195.1020504@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?474B1B9E.2080703>