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."
"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!
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 :-)