Date: Mon, 25 Sep 2000 06:04:18 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: John Polstra <jdp@polstra.com>, arch@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <Pine.SUN.3.91.1000925055843.15658A-100000@pcnet1.pcnet.com> In-Reply-To: <200009250533.e8P5XKg79352@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1000925055843.15658A-100000>