Slashdot Mirror
libkse to libpthread switch on FreeBSD
Dan writes "Daniel Eischen says that libkse has been renamed back to libpthread and is now the default threads library. The gcc-pthread option has also been changed to link to libpthread instead of libc_r. For alpha and sparc64 machines, libkse has not been renamed and links are installed so that libpthread points to libc_r. FreeBSD GNOME team's Joe Marcus Clarke confirmed that the ports system will switch to using libpthread as the default for PTHREAD_LIBS shortly. A patch set is currently being tested, once that completes, the necessary port hooks will be in place to easily build applications linked to libpthread."
... according to some, but I think it's rather useful. The old saying "Don't put your eggs in one basket" applies. (Friendly) Competition is good for open source software - witness KDE and Gnome's attempts to out-innovate eachother.
I don't think for one minute that SCO's claims about Linux are legitimate, but imagine if they were: and some idiot judge ordered that Linux distribution was stopped. I think all the BSD trolls might be glad of an alternative kernel and userland under those circumstances!
"Kernel threads" will now be the default instead of "user threads." (Many BSDers cringe at this use of the term "kernel threads," since to them it represents the misapplication of a term apropriate only to a thread that runs entirely within the kernel. But the above is a usage common in the Linux world.)
This is a key step on the way to finishing the work for FreeBSD 5 and moving on to FreeBSD 6. It incorporates a highly sophisticated (some would say over-sophisticated) M:N threading system; this is where a new kernel-scheduled context is created only for threads that the userland scheduler thinks may block as opposed to having a kernel context for each thread like Linux does. It remains to be seen if the theoretical advantages of this approach will be turned into real-world advantages. I suspect that it will be a while before we know; although libkse has proven stable of late, there will be lots of additional experience acquired now that it is the default and no doubt this will result in further tuning.
Congrats to the FreeBSD team! This and the (not entirely unrelated) SMPng subsystem were the biggest steps on the way to getting FreeBSD 5 ready to take the FreeBSD mantle. It was a gamble going this route rather than the "safe" alternative of a 1:1 model, and there were times when a number of folks wondered if libkse would ever be finished. Well, now it is!
It's intersting that the architects of Windows NT came to the same conclusion back in the 1980s.
I personally don't believe that what's best for NT, Linux and now Solaris is necessarily best for FreeBSD, but the fact that the leading OS (NT), leading open-source OS (Linux) and leading UNIX OS (Solaris) all decided on 1:1 (belatedly in the case of Solaris) is certainly an endorsement of it.
IIRC, one of the main reasons Sun chose an M:N model for Solaris was to ease the porting of old UNIX software that assumed user-mode threads libraries in lieu of real threads (this sort of software ran notoriously badly when ported to NT). With most UNIXes (and even Linux) having had real threads for some time now, this sort of software has become less common, and there isn't such a need to support it, hence the move to 1:1.
I'd be interested to know why the FreeBSD team chose an M:N design, and in what areas their design is expected to be superior to a 1:1 model, or to the old Solaris M:N model.
I think some folks would disagree that libthr wasn't successful -- libkse seemed for all intents and purposes stalled until libthr came along and gave it a kick in the pants. In addition, libthr helped show how the KSE mechanism had a clean enough separation of policy and implementation to support alternative models. If at some point it's decided that the M:N model doesn't work out -- even for just a limited number of applications -- an alternative could quickly be made available. Although KSE's still aren't entirely without controversy (they complicates development and upkeep in several areas of the kernel), libthr did a lot to calm people's fears at a critical point.
This is a simplification..
KSE is not just M:N but also 1:1
The code to generate new "kernel threads" on the fly if an existing thread blocks is only a small part of what was done (though it was tricky I admit).
Re: KSE and 1:1 vs M:N,
It can be used in either way.
firstly the library can be compiled to create a separate kernel thread for each user thread,
and secondly, the thread creation process can be done in a way that guarantees a kernel thread bound to the new thread. even if the library was compile "M:N".
libthr is another arrow in the quither, but
libkse (as it was called) can do most that libthr
can do. (I think the kernel supported mutex that
libthr can use is probably more efficient than what libkse uses for the same thing (but I haven't
benchmarked them)
We have the option of running in 1:1 mode or in M:N mode with the same code, and we can support 30,000 or so threads in userspace (depending on tuning) and not use 30,000 ses of kernel resources.
As I mentionned in another response, The code we ended up with can run in both 1:1 and M:N modes and the library can be compiled to operate in either mode.
To be fair, we took a long time to do this and SUN changed thir minds on the topic when we had already decided where to go, but either way we have good threads..
It really is quite cute to hit 'H' in top and see Mozilla split into 3 threads..
We have quite a bit of cleaning up to do.. for example the cpu affinity is mostly a fiction at this time, (at least between threads) and the scheduler interractiosn need work..
As I have pointed out.. what we implemented was t thread framework that can be used to implement almost any threading model.. For example we will be able to emulate linux threads (well, we do in linux mode) but linux will not be able to emulate our threading unless they add SAs to their kernel..
We can do:
* process based (clone) threading (e.g. linuxthreads)
* process internal threads (the old single process threads)
* 1:1 system scope threads
* 1:1 process scope threads
* M:N theads with async syscalls. (SAs) We'll see which survives in 5 years :-)
Hopefully this makes a good platform for people to do thread research.. That was a big design goal.. provide general solutions that people can use their imagination to use in ways we hadn't thought of.. That's where libthr came from.. it was a surprise to us.. people whipped it up in a few weeks using the infrastrucure we'd made. (they didn't know how close we were to releasing working code so their stopgap and kse were released almost together :-)