1:1 Threading implementation.

[Robert Watson]

On Tue, 25 Mar 2003, Jeff Roberson wrote:

> Thanks to the foundation provided by Julian, David Xu, Mini, Dan
> Eischen, and everyone else who has participated with KSE and libpthread
> development Mini and I have developed a 1:1 threading implementation. 
> This code works in parallel with KSE and does not break it in any way. 
> It actually helps bring M:N threading closer by testing out shared bits. 

My feeling is that this is an excellent strategy to get us productionable
kernel-supported threads for the upcoming 5.x release while permitting
continued R&D (and I think it is R&D) into the M:N threading
possibilities.  One nice thing about this construction is that the cost
was very low given the existing investment in KSE, yet the payoff is very
high.  And it will provide a nice migration path when KSE is
productionable for sites interested in doing that: thread-reliant
applications will no longer be explicitly linked against a non-native
threading package (linuxthreads), which is the status quo for large
threaded applications on FreeBSD right now.  So it seems to me that a
relatively straight-forward strategy gets things moving:

- Get review, testing, and commit this work in short order, and get the
  native threaded support in use.  This will improve support for
  applications like Apache2, MySQL, Open Office, Mozzila, etc, with an
  immediate impact on performance, interactiveity, and throughput for
  these systems, especially for disk I/O intensive activities.  Getting it
  in faster will dramatically increase the chances of fully productionable
  native threads for FreeBSD 5.1.

- We'll also be able to get services like threaded debugging, etc, up more
  easily with this model in the short term, as well as learn a lot more
  about their interactions with threads and what the desired semantics
  are.  This work should have a pay-off for M:N threads easily as well.

- Allow the libkse work to continue over the longer term, and make it
  easier to "plug and play" threading since large threaded apps can use
  either library trivially through library renaming.  The exposed API is
  presumably POSIX, and the ABI to the application should be identical. 
  Any test suites working at the pthreads layer should also immediately
  carry over.  And we've gained some expertise.  :-) 

I think one important thing this will address, and Terry has alluded to
it, is the perception that higher performance threading support is
stalled, and therefore standing in the way of other work.  We have
consumers today who desperately need improved threading support: and they
will benefit a lot from 1:1 in the short term.  They may well benefit more
from M:N in the long term, but I agree that I've had similar concerns
about the scope of the userspace work remaining to be done, especially
from my conversations with Jon Mini.  We may have underestimated this task
substantially; while it could be it falls out naturally, Terry's notion of
"an insurance policy" is far from a bad one.  And since this doesn't
impede KSE (and builds so nicely off of the substantial KSE investment),
the trade-off seems good.

Thanks (to you, but also to Julian, David, and everyone else who has
invested so much into KSE!)

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories