Subject: Re: the path from nathanw_sa -> newlock2
To: Matthias Scheler <>
From: David Brownlee <>
List: current-users
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
 	for comparison.

 		David/absolute       -- No hype required --