I'm rebroadcasting this to current-users since I got many mails like this one.

On Mon, 20 Jan 1997 23:05:38 -0500 (EST), Carl S Shapiro  
<cshapiro@ic.sunysb.edu> wrote:
> What about the overhead caused by the increased number of context switches?
> How would this be resolved?

I was just trying to find a definite answer to that in the docs flying around  
here, and I swear one of the research papers published by CMU gives the  
definite answer to that.  Now, if I could just find it.. *sigh*..

ftp://mach.cs.cmu.edu/ has all those docs, btw.

Context switches don't increase as much as one might think, since you're not  
really context switching an entire process image, but rather only program  
counter and a few other insignificant things.  The advantages of a threaded  
kernel are so great, that even with slightly increased context switching  
overhead by the increased amount of context switches, the context switch  
itself is fairly fast.

In addition to that, continuations used in user-level threads libraries  
reduce the amount of time spent in a context switch even further and increase  
performance. (ftp://mach.cs.cmu.edu/doc/published/cont_threads.ps).   
Continuation alone on a multiprocessor machine can lead to a performance  
increase of up to 75%, and reduce context switch latency by 5% to 49% of  
uniprocessors and multiprocessors.

Mach 3.0 employs continuations in the kernel itself, and allows cross adress  
space RPC's to execute 14% fsater, and exception handling to over 60% faster.
(/doc/published/threadmgnt.ps)

And the list goes on and on.. ;-)

What it boils down to is that threads for themselves allow for design  
features not possible in conventional "serial" processing kernels.

I recommend the bibliography PostScript file for a guide through all the  
publications available from CMU.

--
Christian kuhtz <ckuhtz@paranet.com>