Date: Tue, 10 Oct 2000 08:24:54 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: grog@lemis.com (Greg Lehey) Cc: tlambert@primenet.com (Terry Lambert), jhb@FreeBSD.ORG (John Baldwin), eischen@vigrid.com (Daniel Eischen), arch@FreeBSD.ORG, bright@wintelcom.net (Alfred Perlstein), mark@grondar.za (Mark Murray), jburkhol@home.com (Jake Burkholder), bp@butya.kz (Boris Popov), freebsd-smp@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <200010100824.BAA13123@usr06.primenet.com> In-Reply-To: <20001007132752.A28665@wantadilla.lemis.com> from "Greg Lehey" at Oct 07, 2000 01:27:52 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. [ ... ] > >> 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. 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. Maybe I'm missing some subtlety here that you're not? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200010100824.BAA13123>