Date: Mon, 26 Nov 2007 10:33:57 -0800 From: Julian Elischer <julian@elischer.org> To: Stephan Uphoff <ups@freebsd.org> Cc: FreeBSD Current <current@freebsd.org> Subject: Re: rmlock question.. Message-ID: <474B1195.1020504@elischer.org> In-Reply-To: <474AE5AE.4020301@freebsd.org> References: <4749BB5B.7040801@elischer.org> <4749BBDE.6000107@elischer.org> <474AE5AE.4020301@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. so the quick answer is: "request order is partially preserved, enough to ensure that lockout does not occur." > > > 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?474B1195.1020504>