Date: Sun, 24 Sep 2000 22:33:20 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: John Polstra <jdp@polstra.com> Cc: arch@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <200009250533.e8P5XKg79352@earth.backplane.com> References: <200009241026.e8OAQVx26206@hak.lan.Awfulhak.org> <200009241833.LAA00463@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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.
:
:Just look at the traditional kernel with respect to the spl*() calls.
:...
I gotta gree with John on this. Recursive mutexes can be coded
properly. The best example of this is when you have a module which
implements an API, and to simplify the code you want one API function
to call another in the same module.
The case where one API function may wish to call another is one that
occurs quite often in the kernel. For example, managing ref counts
on objects. If you don't have recursive mutexes, then you do not
have the ability to call your own API recursively (at least not
without creating a mess). You are instead forced to split the API
into a high-level and a low-level piece in order to be able to bypass the
high-level piece. Yuch.
The syscall API is a good example of what happens when you can't
call your own API. For the FreeBSD kernel (and most UNIX kernels that I know),
it is relatively dangerous for one system call to call another system call's
entry point. The inability has created a mess out of things like NFS and
other code elements that use internal descriptors. The last embedded OS I
did allowed system calls to make system calls and it was like night
and day. Things like in-kernel high-level descriptor use became trivial.
-Matt
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?200009250533.e8P5XKg79352>