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

[Attilio Rao]

2008/4/2, Jeff Roberson <jroberson at chesapeake.net>:
>
>  On Wed, 2 Apr 2008, Attilio Rao wrote:
>
>
> > 2008/4/2, Max Laier <max at love2party.net>:
> >
> > > 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
> > >
> >
> > This can't deadlock simply because rw_rlock() is not mutually exclusive.
> >
>
>  It can deadlock if there is a writer waiting in queue depending on whether
> we prefer readers or writers.  I think we should consider the reader/writer
> perference an implementation detail to prevent code like this from cropping
> up.

Ah, right, the writer starvation avoidance will lead to a deadlock here.

Thanks, I didn't consider it, so it is still valid / better to treact
read locks as all the other locks for WITNESS.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein