Subject: Re: newlock
To: Jason Thorpe <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 09/03/2006 17:24:11
Jason Thorpe wrote:
> On Sep 3, 2006, at 3:13 AM, Hans Petter Selasky wrote:
>> 1) Try to avoid using function/structure names already defined by by the
>> FreeBSD mutex implementation, "man mutex", so that one can put an
>> layer on top that emulates FreeBSD mutexes on NetBSD.
> The goal is for the NetBSD API to be like the Solaris API. That was
> my intent when I originally wrote this code.
The Solaris API works really, really well.
I wish instead of "simple_locks", and "splx" and such we just had
mutexes and spl() was handled under the covers.
>> 2) Mutexes must allow recursation.
> Absolutely NOT. Recursive mutexes are just plain evil. The goal is
> to have a BETTER locking API, not have the same warts as the crappy
> one that we currently have.
Recursive mutexes have their uses, but mostly they wind up being a
crutch for poor design, I think. I agree with Jason here.
>> 3) Nice if there are some functions that can drop/pickup the recursation
> Not applicable.
>> 4) You need to implement mutex_sleep(), like there is "ltsleep" for
>> simplelocks. Try to avoid the function name "msleep()".
> What's wrong with msleep() as a name?
I'd rather have actual condition variables than "msleep" and such.
Condition variables are really, really useful for a variety of
purposes. But I'm probably corrupted by having so many pleasant
experiences developing for Solaris. :-)
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191