> The first problem I see is blocking I/O.  Right now, we cannot handle
> the case where multiple threads are reading or writing to the same
> device, or more simply, are asleep via tsleep().  Also, many things in
> the kernel assume a process, not a thread, is waiting on an event,
> holds a lock, etc.
	:
> How hard would it be to extend the tsleep() functions to handle a
> (process,thread) tuple, rather than just a process?  Or is this even
> the right way to go?

Please read the papers about scheduler activations [1] [2] [3], 
on scheduler activations model, theses problems are resolved quite
simpley/efficiently.
Although it seems that the design/implementation of [3] is not quite right,
and avoids merits of schedular activations. So it is better to read
[1] and [2] carefully before [3].

> In short, I think the kernel should manage at least some of the
> process's thread queues.
> 
> For instance, if the kernel managed the runable thread queue, it
> could, on every scheduler tick, decide if it should switch to another
> thread or not.  A syscall could be provided to tell it not to (for
> thread-atomic operations) and when it was safe again.
	:
> Another syscall would alter a thread, moving it from one queue to
> another, perhaps terminating the thread completely.

Kernel have to manage kernel thread (i.e. scheduler activation)'s
queue. But kernel don't have to manage userland thread queue.
On scheduler activations model, all userland synchronization primitives
will be managed by userland thread engine, thus, these privitime have
no overhead of kernel call.

[1]
Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska and Henry M. Levy.
"Scheduler Activations: Effective Kernel Support for the User-Level 
Management of Parallelism," Proceedings of the Thirteenth Symposium 
on Operating System Principles, Oct. 1991, pp.95-109
This is also selected on "ACM Transactions on Computer Systems",
Volume 10, No. 1 (Feb. 1992).

[2] ftp://ftp.cs.washington.edu/tr/1992/08/UW-CSE-92-08-03.PS.Z
BARTON-DAVIS,MCNAMEE,VASWANI,LAZOWSKA
"Adding Scheduler Activations to Mach 3.0"

[3] ftp://das-ftp.harvard.edu/techreports/tr-31-95.ps.gz
Christopher Small, Margo Seltzer. 
"Scheduler Activations on BSD: Sharing Thread Management Between Kernel 
and Application." TR-31-95, 1995.

And also, Calvin Vette introduced the following paper:

> Message-ID: <375462E6.F63C1DFB@borders.com>
> Date: Tue, 01 Jun 1999 18:47:02 -0400
> From: Calvin Vette <cvette@borders.com>
> To: tech-smp@netbsd.org
> Subject: Where do we go from here?
> 
> http://www-masuda.is.s.u-tokyo.ac.jp/publications/theses.html
> Masuda Laboratory Theses
> 
> It appears that Atsushi Ohnoki wrote and implemented a user/kernel-thread
> mechanism for NetBSD in the spring of 1997, upon which he based his master's
> thesis. I had acquired a paper copy of the thesis, and it (the paper) was
> good. I don't have permission to republish it. I haven't been able to track
> down Mr. Ohnoki through the University, and my requests to have an electronic
> copy, as well as my request to convert and web-publish the document,
> were unanswered (but earlier requests were).

(although I have not read a copy of the paper.)
--
soda