No subject

in the kernel is *much* more expensive than a context swtich outside of
the kernel.  I've got loads of multi-threaded programs that run faster
under green-threads than under native threads, since they do very little
kernel calls, but do quite a bit of context switching.

By not having all threads be 'kernel threads', you can take advantage of
the fact that not all 'threads' need to be in kernel space.  This is
essentially the N-M mapping of threads in Solaris, which is a pretty
good model if you can tune the application that manages the threads to
take advantage of this fact.

As far as 'material' on this topic, there's actually alot of good
information on them, but I don't have the pointers off-hand.  Late last
year, we had a long discussion about this in the freebsd-arch
discussion, and a number of URL's were posted describing the speedups
from having the mixed model that Solaris uses.  There are tons of
IEEE/ACM papers on this, so finding papers should be trivial.

Or, you can grep through the freebsd-arch archives (not sure where they
are online, but maybe deja-news has them) and look for the thread
discussion that went on there.

Basically, for a large class of applications, a 'kernel thread', such as
what is used by most OS's, (NT, Linux, and Solaris) has a big context
switching hit, that is overkill.




Nate

---
To unsubscribe, mail advanced-java-unsubscribe at xcf.berkeley.edu
To get help, mail advanced-java-help at xcf.berkeley.edu