Date: Mon, 25 Sep 2000 07:59:12 -0700 (PDT) From: Frank Mayhar <frank@exit.com> To: Terry Lambert <tlambert@primenet.com> Cc: mjacob@feral.com, Brian Somers <brian@Awfulhak.org>, Greg Lehey <grog@wantadilla.lemis.com>, Chuck Paterson <cp@bsdi.com>, Archie Cobbs <archie@whistle.com>, Joerg Micheel <joerg@cs.waikato.ac.nz>, John Baldwin <jhb@pike.osd.bsdi.com>, Mark Murray <markm@FreeBSD.ORG>, FreeBSD-arch@FreeBSD.ORG.ORG Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files Message-ID: <200009251514.e8PFET802275@realtime.exit.com> In-Reply-To: <200009250827.BAA12659@usr02.primenet.com> from Terry Lambert at "Sep 25, 2000 08:27:55 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > With the suggested mutex recursion (please -- use a counting > semaphore, not a mutex, if you are going to permit recursion!), That's basically what it is, more or less. > If you are willing to whine about recursion, then I suppose > that having recursion would not be that bad; but turn off > the whining, and there's little incentive to fix it, since > to many people's minds, it won't be broken. 8-(. Well, I can't speak for FreeBSD, but as far as BSD/OS goes, I plan to fix this stuff. I cut my teeth on SVR4.2 ES/MP, so I'm not used to recursive locks anyway, and I quite agree that if the code _needs_ a recursive lock, there's more going on there and the possibility of deadlocks is high. My code doesn't use recursive locks. Yeah, it's more work, but it's well worth it in the long run. I think it's a relatively small price to pay for long-term reliability and for not needing to go back and reexamine everything down the road a bit. (I hope this makes sense; I haven't had my coffee yet. :-/) -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://store.exit.com/ 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?200009251514.e8PFET802275>