From owner-freebsd-arch Mon Sep 25 3: 4:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 4689837B422 for ; Mon, 25 Sep 2000 03:04:43 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id GAA16555; Mon, 25 Sep 2000 06:04:18 -0400 (EDT) Date: Mon, 25 Sep 2000 06:04:18 -0400 (EDT) From: Daniel Eischen To: Matt Dillon Cc: John Polstra , arch@FreeBSD.ORG Subject: Re: Mutexes and semaphores In-Reply-To: <200009250533.e8P5XKg79352@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 24 Sep 2000, Matt Dillon wrote: > > 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. Mutexes should protect data. If you want to allow recursive ownership of data, then keep your own owner and ref count field in the protected data and use the mutex properly (release it after setting the owner or incrementing the ref count). You don't need to hold the mutex, and now you can use the same mutex for msleep/cv_wait. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message