From owner-freebsd-smp Tue Oct 10 1:46:38 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 0C8C537B503; Tue, 10 Oct 2000 01:46:31 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e9A8kL289653; Tue, 10 Oct 2000 18:16:21 +0930 (CST) (envelope-from grog) Date: Tue, 10 Oct 2000 18:16:21 +0930 From: Greg Lehey To: Terry Lambert Cc: John Baldwin , Daniel Eischen , arch@FreeBSD.ORG, Alfred Perlstein , Mark Murray , Jake Burkholder , Boris Popov , freebsd-smp@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <20001010181621.M87663@wantadilla.lemis.com> References: <20001007132752.A28665@wantadilla.lemis.com> <200010100824.BAA13123@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200010100824.BAA13123@usr06.primenet.com>; from tlambert@primenet.com on Tue, Oct 10, 2000 at 08:24:54AM +0000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 10 October 2000 at 8:24:54 +0000, Terry Lambert wrote: >>> A mutex is not recursive. There are things you simply can not >>> implement when recursion is permitted for all of your primitives. >>> >>> The most obvious argument is still that a mutex is intended to >>> protect data, not code. Recursion is only required if the mutex >>> is actually protecting reentrancy of code, not access to data. I suppose I should have left this last paragraph of the quote out. The intention of mutexes is left to the programmer. While I agree that I'd rather use them to protect data than code, there's nothing in the nature of a mutex that requires that. >>>> do NOT use printf without Giant. >>> >>> This strikes me as being rather inane. >>> >>> If printf won't work without holging the lock, then it damn well >>> should acquire the lock if it isn't already held, and release it >>> if it acquired it, before returning. >> >> Make up your mind. > > I see no conflict. The printf should not fail unless it is > the result of a data protection failure. > > Testing to see that the giant lock (which is not a mutex) is > held, if it is truly a requirement to hold it, is not a problem. Giant is a mutex. > Acquiring the giant lock only if it is not already acquired, and > only releasing it if it wre you who acquired it, is not recursion. Well, for some definition of "recursion". I don't know if the term "recursive" is even appropriate for this behaviour. But if you find yourself in a position where you need to check whether you need to acquire a mutex, then "recursion" is the cheapest way to go. > Maybe I'm missing some subtlety here that you're not? Well, also that your alternative is even untidier than recursion. The whole original discussion boils down to "properly written code only needs to lock once". I tend to agree with this viewpoint, but it's clear that by that measure we have a lot of improperly written code. Recursion isn't the problem, it's the solution. You're advocating rejecting the solution ("because recursion is bad") and replacing it with a worse solution ("did we lock? OK, then we need to unlock now"). At the very least, that requires auxiliary variables which aren't part of the mutex, which is very untidy, especially if you have to debug the thing. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message