On 2001.06.12 01:20:02 ali (Anders Lindgren) wrote:
> This is kind of an interesting issue. People often put forward that Linux
> "kernel threads" suck because "one process/thread is known to be an
> inefficient way of implementing kernel threads", but I haven't really
> heard any arguments as to why it necessarily has to be? Why would it
> be inherently more inefficient than LWPs, which is just another layer
> put in between the unix proc structs and the scheduler (in SUNs
> implementation anyway) anyway?

Usually because of the context-switch overhead: to switch between
threads within a process will require a full kernel context-switch
(going into protected mode, etc.). This can usually be handled far
more efficiently in user-mode. Even the simplest system-call incurs
some overhead.

But entirely user-level threads requires contortions to properly
handle potentially-blocking calls. The ideal solution is some
combination of the two.

You could try reading `Scheduler Activations: Effective Kernel Support
for the User-Level Management of Parallelism' (Anderson et al.
<http://citeseer.nj.nec.com/anderson92scheduler.html>); I'm pretty
sure it covered a lot of the issues. This is the model to be used by
NetBSD, from what I understand.

-- 
"Source code in files. How quaint." - Kent Beck
"Maybe this world is another planet's Hell." - Aldous Huxley