Technical Linux questions

[gaf at blu.org (Jerry Feldman)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It's too bad that Dave Butenhof is not on this list, but.
On Tru64 we had both kernel and user threads. A threaded application
would get a number of kernel threads based on the number of CPUs. Then
the user threads were mapped to the per CPU kernel threads as deemed
necessary. 
On Fri, 21 Feb 2003 17:57:07 -0500
Derek Martin <blu at sophic.org> wrote:

> It's much more than that.  In order to do user-space threads, you need
> to have preemptable system calls, or write wrappers around existing
> system calls, or replace them with select().  You need this because
> otherwise, if a thread blocks on a system call, the whole process
> blocks, and no other thread can run (which pretty much blows away any
> benefit of having threads in the first place).
> 
> Implementing kernel threads prevents that, and also saves the
> application developer from having to write complicated thread
> scheduling code, which makes apps which use kernel threads much easier
> to write and debug than those that implement user-mode threads.  But,
> at the expense of speed (kernel threads require the equivalent of a
> context switch in the kernel, where user-mode threads don't) and a
> more complex kernel (to implement the thread scheduling, and memory
> sharing).
> 
> I think in general, the more threads look like processes, the less
> complex the kernel gets, but the less efficient thread switching
> becomes.  Like everything else, it's a tradeoff.


- -- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Vr7k+wA+1cUGHqkRAs6yAJ9leHIHD7+ZJAx38MJidB5qW2tVIQCfa5Bc
/vW0jRX/TBPmKW3BzFetFWc=
=0zJm
-----END PGP SIGNATURE-----