Kamal Prasad <kamalpr@yahoo.com> writes:

> --- Bill Studenmund <wrstuden@netbsd.org> wrote:
> > Kernel threads are available and used. User level
> > threads have no kernel
> > support; you have to use userland threading
> > libraries.
> > 
> is there an architevctural reason why we cannot attach
> userlevel threads to a kernel level thread (the way
> its done in Solaris)?

The kernel threads Bill refers to are really process-level entities
that simply spend their entire life in the kernel. Referring to them
as "threads" is somewhat misleading; while the "kernel threads" share
the kernel address space, they're scheduled in the traditional
cooperative way. Our kernel is not a generally preemptable thread
system.

It is possible to create multiple kernel-scheduled entities
(processes, really), have them share an address space, and bind
userlevel threads to them. We have the __clone() system call, adopted
for Linux and principally implemented for Linux emulation, that does
this.

On the branch I've been working on ("nathanw_sa"), there is an
additional, somewhat Solaris-like LWP construct, which is the
schedulable entity, and there can be multiple LWPs per process. It is
possible, with that code, to bind user threads one-to-one with LWPs in
a process.

The thread system I'm implementing on the branch does something
more complicated, hopefully with some benefits to show for it; have a
look at my Usenix paper on the subject at
http://web.mit.edu/nathanw/www/usenix/.

        - Nathan