From: Greg Green (ggreen_at_cs.washington.edu)
Date: Mon Jan 26 2004 - 12:53:25 PST
This paper relates a technique for tying together user-level threads
with the kernel on a multiprocessor system to prevent problems
presented by using either kernel threads or user-space threads. The
design is to use a construct called a scheduler activation which calls
back into user-space thread management with all kernel events that can
affect user space threads. With this information in hand, the
user-space thread management can then do the appropriate
action. Another part of the method is for the user threads to tell the
kernel that it needs more or less processors.
The specific events that are up-called into user-space are: processor
has been preempted, the kernel has blocked this activation, the kernel
has unblocked this activation. A complication that can arise is if a
user thread is in a critical section, and is preempted by the
kernel. The critical section needs to be resumed until exited when the
activation gets the processor back so that it can release the lock. A
clever method of copying the instructions of the critical section is
used so that when the activation is resumed, it calls the user thread
management routine for rescheduling after the critical section is
exited. To sum up, activations allow the developer to have the
advantages of kernel-threads with the speed of user-level threads.
I knew little about user threads vs kernel threads before reading this
paper, so most of the information was new to me. In that respect
alone, it was quite enlightening. I thought the design detailed here
was quite clever. This is similar to the concept of wake-up predicates
in the exokernel idea, but in reverse. It also educated me on the
dangers of user space threads, none of which I knew about before. The
mechanism seems secure, simple, and general. I would like to know if
any os has actually used this concept. I was also unaware of the large
speed differences between kernel threads and user threads.
-- Greg Green
This archive was generated by hypermail 2.1.6 : Mon Jan 26 2004 - 13:19:52 PST