Subject: Re: What is happening with libpthread???
To: None <current-users@NetBSD.ORG>
From: Christian Kuhtz <firstname.lastname@example.org>
Date: 01/20/1997 22:39:20
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
> 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
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.
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 <email@example.com>