Date: Wed, 02 Apr 2008 01:15:47 +0200 From: Kris Kennaway <kris@FreeBSD.org> To: Max Laier <max@love2party.net> Cc: Attilio Rao <attilio@freebsd.org>, cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_rwlock.c src/sys/sys rwlock.h Message-ID: <47F2C223.6010705@FreeBSD.org> In-Reply-To: <200804020025.57684.max@love2party.net> References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <200804020025.57684.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. One situation is that try_[rw]lock can be used to bail out completely if you are doing something optional. e.g. you might have code that is doing some optimization like prefetching of data that can be just skipped if the lock (read or write) cannot be immediately obtained. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47F2C223.6010705>