cvs commit: src/sys/kern kern_rwlock.c src/sys/sys rwlock.h

[David Schultz]

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...