Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Sep 2000 15:19:55 -0400 (EDT)
From:      Daniel Eischen <eischen@vigrid.com>
To:        arch@FreeBSD.ORG
Cc:        arch@FreeBSD.ORG
Subject:   Re: Mutexes and semaphores
Message-ID:  <Pine.SUN.3.91.1000924151251.7740A-100000@pcnet1.pcnet.com>
In-Reply-To: <200009241833.LAA00463@vashon.polstra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 24 Sep 2000, John Polstra wrote:
> In article <200009241026.e8OAQVx26206@hak.lan.Awfulhak.org>,
> Brian Somers  <brian@Awfulhak.org> wrote:
> > > 3.  The mutex can also be "recursive" (it's really iterative, I
> > >     suppose): the owner can take it several times.  The only reason
> > >     for this appears to be sloppy coding, but in the short term I
> > >     think we're agreed that we can't dispose of that.
> > 
> > I agree - the idea of recursive mutices evil and should go, but the 
> > idea of an owner should not.  It's nice to be able to write code that 
> > KASSERTs that it already owns a given mutex.
> 
> I disagree that recursive mutexes are bad, and I don't think "sloppy
> coding" is the right way to look at them.  I would argue that
> recursive mutexes allow robust code to be written based solely on
> knowledge of the immediately surrounding code, and that is a Good
> Thing.
> 
> There are plenty of reasonable situations where you have a block of
> code (say, a function) and a certain mutex needs to be locked while
> it executes.  The function might be called from several different
> places.  Maybe all of the call sites already hold the mutex, and
> maybe they don't.  Maybe it is hard to say for sure.  Maybe new calls
> will be added in the future which will add further uncertainty.  With
> recursive mutexes you can make the code robust by locking the mutex
> inside the called function.  This robustness is certain and it is
> independent of what is going on in the rest of the system.

But you can't then use a recursive mutex in conjunction with msleep
(cv_wait) which forces you to use yet another mutex.  This is fine,
but it adds confusion for the programmer.  Another thing, is in
our support for recursive mutexes is that they make the calling
conventions overly complex (with the silly flag argumuents to
mtx_enter()).

If we are going to support recursive mutex, I think it would be
better to add separate calls/macros/data types to support them,
so the the mtx mutexes can be simplified.  Calls to mtx_enter
with the recursive mutex type wouldn't even compile.

My $0.02 for what it's worth...

-- 
Dan Eischen



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1000924151251.7740A-100000>