Date: Wed, 26 Mar 2003 09:31:13 -0500 (EST) From: Robert Watson <rwaston@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@freebsd.org Subject: Re: 1:1 Threading implementation. Message-ID: <Pine.NEB.3.96L.1030326091839.3931I-100000@fledge.watson.org> In-Reply-To: <20030325214028.K64602-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030326091839.3931I-100000>