Subject: Re: the path from nathanw_sa -> newlock2
To: Matthias Scheler <firstname.lastname@example.org>
From: David Brownlee <abs@NetBSD.org>
Date: 02/12/2007 14:08:50
On Mon, 12 Feb 2007, Matthias Scheler wrote:
> On Mon, Feb 12, 2007 at 12:00:21AM -0800, Aaron J. Grier wrote:
>> On Sun, Feb 11, 2007 at 11:03:47PM +0000, Matthias Scheler wrote:
>>> I don't know all the details. What I can remember is:
>>> 1.) Our M:N implementation never worked properly on multiple CPUs.
>>> 2.) It didn't work very well on certain platforms e.g NetBSD-sparc
>>> and NetBSD-sparc64.
>> both of which could've been addressed, no?
> Unfortunately nobody was able to fix those issue in the last few *years*.
> POSIX threads are broken on NetBSD-sparc and NetBSD-sparc64 in 2.0, 3.0
> and will still be broken in 4.0.
> My hope is that with "newlock2" they'll work at least in NetBSD 5.0.
The goal for newlock2 was to rework the NetBSD kernel to
permit multiple concurrent processors in the kernel for
SMP, rather than the previous biglock SMP implementation
where (effectively) only one processor could be in the
kernel at any given time (though any number of CPUs could
be running userland code)
M:N schedular activation thread implementations are complex
and very hard to get right. There is a very small number
of people who really understand NetBSD's implementation.
Getting NetBSD's M:N thread implementation to work under
the newlock2 branch would have involved Andrew spending a
large quantity of time working with it. Simply getting it
working correctly in all cases _before_ starting newlock2
could wasily have taken longer then his writing the entire
newlock2 branch with its own 1:1 (easy to test and prove
correct) thread implementation.
What would have been most likely is he would have got bogged
down trying to fix obscure and hard to reproduce and debug
issues, and we would have ended up with a few M:N issues
fixed, but still not working correctly on even the biglock
SMP, and no newlock2 code.
I believe he covered the options in his proposal to core, and
they made the (right) choice on how to proceed.
The current situation does not preclude someone with the
desire to reimplement a M:N threading system, but with any
luck they will be doing it on a kernel which has real SMP,
and a reference _completely working_ 1:1 threading system
David/absolute -- www.NetBSD.org: No hype required --