Date: Tue, 10 Oct 2000 18:16:21 +0930 From: Greg Lehey <grog@lemis.com> To: Terry Lambert <tlambert@primenet.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, Daniel Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG, Alfred Perlstein <bright@wintelcom.net>, Mark Murray <mark@grondar.za>, Jake Burkholder <jburkhol@home.com>, Boris Popov <bp@butya.kz>, freebsd-smp@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <20001010181621.M87663@wantadilla.lemis.com> In-Reply-To: <200010100824.BAA13123@usr06.primenet.com>; from tlambert@primenet.com on Tue, Oct 10, 2000 at 08:24:54AM %2B0000 References: <20001007132752.A28665@wantadilla.lemis.com> <200010100824.BAA13123@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001010181621.M87663>