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

[Max Laier]

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

Can this deadlock?  How?

If thread C did: rw_wlock(RW) ... mtx_lock(MTX) ... UNLOCK or the other 
way around, I can see that it will[1] deadlock, but with the wlock 
without a lock order wrt the MTX, I can't see it.  Plus, can we teach 
WITNESS to keep quite about thread A and B unless we also see a lock 
order with the wlock and the mutex?

[1] In fact, thinking about it right now ... if thread C did: 
mtx_lock(MTX) ... rw_slock(RW) ... UNLOCK it might still be okay.  IIRC 
we allow rlocks to succeed as long as there are other rlocks held.  
Though this might be historical behavior to support recursion.  I see 
that we wouldn't want to rely on this to avoid live locks.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News