From owner-freebsd-arch Sun Sep 24 22:33:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843290.broadbandoffice.net [64.47.83.26]) by hub.freebsd.org (Postfix) with ESMTP id 7FA8437B43C for ; Sun, 24 Sep 2000 22:33:31 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.0/8.9.3) id e8P5XKg79352; Sun, 24 Sep 2000 22:33:20 -0700 (PDT) (envelope-from dillon) Date: Sun, 24 Sep 2000 22:33:20 -0700 (PDT) From: Matt Dillon Message-Id: <200009250533.e8P5XKg79352@earth.backplane.com> To: John Polstra Cc: arch@FreeBSD.ORG Subject: Re: Mutexes and semaphores References: <200009241026.e8OAQVx26206@hak.lan.Awfulhak.org> <200009241833.LAA00463@vashon.polstra.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In article <200009241026.e8OAQVx26206@hak.lan.Awfulhak.org>, :Brian Somers 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