On Wed, 25 Jun 2003, Jason Thorpe wrote:

: I think it's important to remember that Solaris's M:N implementation
: was particularly poor; it did indeed suffer from performance problems,
: and a host of other issues.

"Sounds familiar."

: They were, however, artifacts of their particular implementation of
: M:N, not properties inherent to the M:N strategy.

So what?  *NetBSD*'s pthreads project has been how long coming with
completely unstable (forget even thinking about performance yet!) results?

You mentioned earlier in this thread that 1:1 implementation would be "more
difficult."  I have quite a hard time believing that in the context of real
LWP attachment (as opposed to clone(2)-based, for instance), since it means
near zero need for userspace context jumping.  If the kernel is in charge of
the context switches, the stability difference against the current approach
*should* be quite noticeable.

Now, for the purposes of having *any* kernel-assisted threading at all
(since we're still stumbling while everyone else has jumped the hurdle and
kept on going), the performance difference for 1:1, while known to exist,
should not be alarmingly huge.  All previous attempts to benchmark in favor
of either approach have been documentably slanted in favor of one of the two
directions to show any appreciable performance gain.

I'm quite the bit surprised that we didn't go the 1 thread to 1 LWP route
before adding M:N as an additional feature.  Going 1:1 first would not have
meant "doing it wrong" or "doing it the non-NetBSD way"; it would simply
have meant "doing it in stages."  So why not insert a 1:1 code path as
default now, to gain stability, and resurrect M:N in NetBSD 2.1?

Compromise here, folks....

-- 
-- Todd Vierling <tv@pobox.com>