Date: Wed, 2 Apr 2008 10:55:20 -0400 From: David Schultz <das@FreeBSD.ORG> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Attilio Rao <attilio@FreeBSD.ORG>, 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: <20080402145520.GA21462@zim.MIT.EDU> In-Reply-To: <20080401123951.J72156@desktop> References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <200804020025.57684.max@love2party.net> <20080401123951.J72156@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 01, 2008, 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. One reason that many systems don't provide a rw_try_wlock() primitive is that a constant stream of readers can easily starve threads attempting to acquire the write lock without waiting. There are probably situations where this isn't a problem, though, e.g., if readers rarely hold the lock for a long time...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080402145520.GA21462>