cvs commit: src/sys/kern kern_rwlock.c src/sys/sys rwlock.h
max at love2party.net
Tue Apr 1 17:03:07 PDT 2008
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
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 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?
 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
More information about the cvs-all