Jason Thorpe wrote:
>
> 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*).

I love this idea.  Doing this would be a huge step in the right
direction, and then we could start making the changes.

By the way, some years ago (many years ago) Sun was faced with the
challenge of converting old drivers to an MP safe architecture.  They
required drivers to report that they were MP safe (D_MP in the driver
flags), and after a release or two, they dropped all support for drivers
that failed this check.   It might make an interesting model for how to
get there.

Of course, the first thing we need is an infrastructure (in terms of
API) to support it.  Even if internals of the API are not implemented in
an MP safe way, as long as they can be converted to be MP safe later,
then folks can start updating drivers to whatever new API we expose _today_.

Maybe I need to look more closely at newlock etc. to see if there is
anything I can do to help.  I've just been bogged down with other stuff
lately.

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191