From owner-freebsd-arch Sun Sep 24 11:33:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id B9A1E37B422 for ; Sun, 24 Sep 2000 11:33:25 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id LAA10553 for ; Sun, 24 Sep 2000 11:33:24 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id LAA00463; Sun, 24 Sep 2000 11:33:23 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Sun, 24 Sep 2000 11:33:23 -0700 (PDT) Message-Id: <200009241833.LAA00463@vashon.polstra.com> To: arch@freebsd.org Reply-To: arch@freebsd.org Subject: Re: Mutexes and semaphores In-Reply-To: <200009241026.e8OAQVx26206@hak.lan.Awfulhak.org> References: <200009241026.e8OAQVx26206@hak.lan.Awfulhak.org> Organization: Polstra & Co., Seattle, WA 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. Imagine if it were illegal to call an spl function which would block one or more interrupts which were already blocked. That kind of restriction would make the code must less robust and much harder to maintain. There is a place for both recursive and non-recursive mutexes in a sound and robust design. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message