Date: Tue, 1 Apr 2008 15:11:11 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: Attilio Rao <attilio@freebsd.org> Cc: Max Laier <max@love2party.net>, src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_rwlock.c src/sys/sys rwlock.h Message-ID: <20080401150918.F72156@desktop> In-Reply-To: <3bbf2fe10804011723w69e38ed7sc5760ea269600654@mail.gmail.com> References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <200804020025.57684.max@love2party.net> <20080401123951.J72156@desktop> <200804020200.58006.max@love2party.net> <3bbf2fe10804011723w69e38ed7sc5760ea269600654@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Apr 2008, Attilio Rao wrote: > 2008/4/2, Max Laier <max@love2party.net>: >> On Wednesday 02 April 2008 00:52:45 Jeff Roberson wrote: >> > On Wed, 2 Apr 2008, Max Laier wrote: >> >> On Tuesday 01 April 2008 22:31:55 Attilio Rao wrote: >> >>> attilio 2008-04-01 20:31:55 UTC >> >>> >> >>> FreeBSD src repository >> >>> >> >>> Modified files: >> >>> sys/kern kern_rwlock.c >> >>> sys/sys rwlock.h >> >>> Log: >> >>> Add rw_try_rlock() and rw_try_wlock() to rwlocks. >> >>> These functions try the specified operation (rlocking and >> >>> wlocking) and true is returned if the operation completes, false >> >>> otherwise. >> >> >> >> hmmm ... I'm certainly missing something here, but what's a possible >> >> usecase for these? It seems there is not much you can do if you >> >> can't obtain a rw_lock. I can understand the need for sx_try_* where >> >> you want to avoid sleeping, but I can't figure out the need for it on >> >> a locking primitive that will only spin or wait (not 100% sure about >> >> the terminology here). This is especially strange for rw_try_wlock, >> >> unless you plan to sleep manually on fail. But then again you'd have >> >> a good chance that you have to do it over and over again if timing is >> >> unfortunate. >> > >> > I asked for it. We have a try operation for mtx already. I was >> > experimenting with converting some code to use rwlocks from mtx and it >> > required it. The specific case is in the softdep code where it uses >> > trylock to avoid deadlocking. With trylock you can violate the >> > lockorder. >> >> >> Makes sense, thanks! A little follow-up, though about something I'm >> wondering about for quite some time now. Take the following scenario: >> >> Thread A: rw_rlock(RW) ... mtx_lock(MTX) ... UNLOCK >> Thread B: mtx_lock(MTX) ... rw_rlock(RW) ... UNLOCK >> Thread C: rw_wlock(RW) ... UNLOCK > > This can't deadlock simply because rw_rlock() is not mutually exclusive. It can deadlock if there is a writer waiting in queue depending on whether we prefer readers or writers. I think we should consider the reader/writer perference an implementation detail to prevent code like this from cropping up. Readers are only allowed to proceed with a read lock if they already own a read lock, not just if the lock is already read locked. This changed in current recently. So a single recursive read acqusition can't deadlock but get multiple threads and a writer involved with writer preference and you can. Jeff > >> Can this deadlock? How? >> >> If thread C did: rw_wlock(RW) ... mtx_lock(MTX) ... UNLOCK or the other >> way around, I can see that it will[1] deadlock, but with the wlock >> without a lock order wrt the MTX, I can't see it. Plus, can we teach >> WITNESS to keep quite about thread A and B unless we also see a lock >> order with the wlock and the mutex? > > You mean skipping possible LORs for shared instances of double-sided primitives? > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080401150918.F72156>