Subject: Re: newlock
To: Garrett D'Amore <>
From: Jason Thorpe <>
List: tech-kern
Date: 09/03/2006 18:36:19
On Sep 3, 2006, at 5:24 PM, Garrett D'Amore wrote:

> I wish instead of "simple_locks", and "splx" and such we just had
> mutexes and spl() was handled under the covers.

That is the intent of the "newlock" branch I worked those N years ago,  
that Andrew is now picking back up.  I basically sat down with my copy  
of _Solaris Internals_ and wrote a clone implementation of the Solaris  
turnstiles, mutexes, and rwlocks.

> Recursive mutexes have their uses, but mostly they wind up being a
> crutch for poor design, I think.  I agree with Jason here.

Exactly.  If you NEED a recursive mutex, your code structure needs to  
be fixed.  If you can't avoid it, then your (poorly-designed)  
subsystem can implement its own using mutexes underneath.

> 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. :-)

Yah, a real CV implementation could be nice; but then again, it is  
also really handy to have any arbitrary identifier available as a  
sleep identifier.

That said, I DID do a turnstile implementation on the newlock branch,  
and turnstiles are very conducive to CVs, and quite scalable.  We  
could certainly do away *sleep() entirely (by fully adopting  
turnstiles and CVs) and eliminate the big fat "scheduler lock", which  
is pretty much guaranteed to be a barrier to MP scalability (not that  
it matters much in the NetBSD kernel right *now*).

-- thorpej