Date: Wed, 2 Apr 2008 23:30:01 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: David Schultz <das@FreeBSD.ORG> 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: <20080402232758.L949@desktop> In-Reply-To: <20080402145520.GA21462@zim.MIT.EDU> References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <200804020025.57684.max@love2party.net> <20080401123951.J72156@desktop> <20080402145520.GA21462@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Apr 2008, David Schultz wrote: > 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... > The same applies to constant streams of lockers with a normal mutex. We have found a few cases now where trylock was used that basically never succeeded and caused pessimal behavior. I'm not really a fan of it myself but it is (ab)used in some scenarios and having it in rw will make changing from mtx easier. I think it would be a good task for someone to attempt to remove uses of trylock by restructuring the locking. Thanks, Jeff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080402232758.L949>