Date: Wed, 27 Sep 2000 22:00:22 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eischen@vigrid.com (Daniel Eischen) Cc: arch@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <200009272200.PAA27464@usr02.primenet.com> In-Reply-To: <Pine.SUN.3.91.1000927163448.26328A-100000@pcnet1.pcnet.com> from "Daniel Eischen" at Sep 27, 2000 05:00:20 PM
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Eischen wrote: > On Wed, 27 Sep 2000, John Polstra wrote: > > > If you absolutley need recursive mutexes, then roll your own and > > > keep the base mutex simple. This is trivial to do and makes the > > > base mutex more efficient without the need to check for recursive > > > ownership. > > > > I think it would make sense to make recursive mutexes a separate > > type, so they don't complicate the non-recursive ones. But the "roll > > your own" idea would work against eventually getting rid of recursive > > mutexes entirely. If they are implemented ad hoc in various places, > > it will be hard to find them all later. Better to have a standard > > implementation that's easy to search for. > > I'll agree to this; I've suggested it before. But I'd like to go > one step further and not make them part of our official API. State > that they are subject to change/removal, perhaps complain loudly > when compiled with -DKLD_API (-DKLD_MODULE ?) or something. I'll third this approach. I personally don't see where they would be useful, but de-grunging the API argument list and putting them in a seperate API (mutex_legacy()?) would be vastly preferrable. I like the idea of being able to grep for "mutex_legacy" to be able to distinguish between code that has been hacked for legacy reasons vs. code that has been intentionally made SMP safe. I'd like to see an option in the config file for "LEGACY_MUTEX" suport, and that it be left out until someone actually uses a recursive mutex. Both of these steps would ensure that the code is not dropped on the floor, making it known in no uncertain terms that mutexes of this type are strongly discouraged. This fits well with Alfred P's arguments on planning push-down of locks, instead of merely hacking it. 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?200009272200.PAA27464>