Subject: Re: libpthread
To: William Henny <willhenny@yahoo.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 06/26/2003 18:03:17
On Fri, 27 Jun 2003, William Henny wrote:

> In article <20030625003728.24391.qmail@web41206.mail.yahoo.com>, Gary Thorpe wrote:
> >
> > And there own test run on Linux shows that the M:N implementation is
> > better (scales better) when compared the 1:1 implementation for this
> > particular OS.
>
> That's nice. Nevertheless, I think it has been established that a 1:1
> implementation can in fact achieve more than 'good enough' scalability at a
> much lower cost in terms of implementation complexity. _That's_ the real
> issue.

Well, as Nathan said, you have the source code. Go for it.

Telling us that we _should_ switch to a 1:1 thread model isn't going to go
over well at this point. Showing us a 1:1 model that you've implemented
may go over quite well, though.

While comparisons of complexity may have made sense initially, they don't
make a lot of sense now. We have an almost-finished M:N implementation,
and we don't have a 1:1 implementation. As my other note listed, there are
a number of non-trivial things a 1:1 implementation will need to get to
where the M:N implementation is now. A number of the open issues, such as
program bugginess and the fact that our scheduler doesn't understand LWPs,
apply equally to 1:1 and M:N models.

So changing directions in mid-stream won't buy us much. It sure looks to
me like an easier thing to do is fix what we have.

Oh, and as Jason noted, Wasabi (where I work) is developing an application
that uses threads. i.e. NetBSD's threading library. As we have uncovered
issues, Nathan has systematicly fixed them. I'd expect the fact our app
was complex but not too complex helped; we tickled issues yet you could
still understand the code paths.

Nathan's commits as of today fix the one remaining issue we'd found, which
was a single-instruction window in which taking an upcall would kill the
program.

So the M:N implementation we have is doing well. As this thread indicates,
it's not finished, but it's doing really well. Given that it's really only
had one developer, I think it's doing great.

Take care,

Bill