Date: Wed, 2 Apr 2008 12:05:34 +0200 From: "Attilio Rao" <attilio@freebsd.org> To: "Jeff Roberson" <jroberson@chesapeake.net> 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: <3bbf2fe10804020305r624ab142j18f00b84f2ae240f@mail.gmail.com> In-Reply-To: <20080401150918.F72156@desktop> References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <200804020025.57684.max@love2party.net> <20080401123951.J72156@desktop> <200804020200.58006.max@love2party.net> <3bbf2fe10804011723w69e38ed7sc5760ea269600654@mail.gmail.com> <20080401150918.F72156@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
2008/4/2, Jeff Roberson <jroberson@chesapeake.net>: > > 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. Ah, right, the writer starvation avoidance will lead to a deadlock here. Thanks, I didn't consider it, so it is still valid / better to treact read locks as all the other locks for WITNESS. 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?3bbf2fe10804020305r624ab142j18f00b84f2ae240f>