From: Jeff Duzak (jduzak_at_exchange.microsoft.com)
Date: Sat Jan 24 2004 - 20:16:51 PST
This paper talks about the limitations of current kernel and user-mode
thread management schemes. A new scheme in which the kernel provides
very generalized support for user-mode management of parallelism is
proposed. This scheme is implemented, and its performance is compared
against a kernel thread system and a user-mode thread system running on
top of kernel threads.
Briefly, the problem with kernel threads is that they are slow (because
they require kernel calls to manage) and that if they are to be made to
support various threading schemes, those schemes would have to be
implemented in the kernel, thus introducing complexity into the kernel.
The problem with existing user-mode thread packages at the time of this
paper was that they ran on top of kernel mode threads which were
scheduled with no knowledge about the needs of the user-mode threads.
Because of this, processing power could be underutilized, and user
threads could remain blocked unnecessarily long or deadlock.
The paper proposes an interesting new way that a kernel can support
user-level thread management, in a way that prevents the problems with
other user-level thread packages. The idea, basically, is that the
kernel would provide to a process (or address space, as processes are
called in this paper) a number of "scheduler activations", each one
representing control of a particular processor. In brief, this scheme
allows the user thread package to 1) know how many processors it has at
its disposal and 2) be notified whenever a user thread is preempted or
blocked within kernel space. The scheme allows the kernel to 1) preempt
a user thread at will, 2) keep exactly one scheduler activation active
per processor (and therefore not have to time-slice between
activations), and 3) be aware of the changing needs of the user thread
packages (in order to ensure that no processor time is wasted).
The performance of the scheduler activation system was compared against
a kernel thread system and an existing user-mode thread system. The
latency of thread management calls on the scheduler activation system
was only slightly longer than on the existing user-mode thread package,
and much shorter than on the kernel thread system. Further, in a
variety of experiments in which certain variables, such as 1) processor
allocation, 2) I/O activity, and 3) contention with other processes,
were manipulated, the scheduler activation system performed
significantly better than the two other systems.
The system described in this paper is actually pretty cool. I like the
fact that the scheme is very clean. As I mentioned, it keeps exactly
one scheduler activation active for each processor, thereby eliminating
the need to time-slice between activations. Once an activation is
inactive, it is dead, forever. It is not simply suspended and then
resumed later at a time which may or may not be convenient for it or the
rest of the process. However, a process holds on to the dead activation
so that it can extract the state of the thread that used to be executing
on that activation. Further, the method of passing events from the
kernel to the user thread package is very clean in that it gives the
process a brand new activation in order to process the events while
maintaining the same total count of activations in the process.
**Presuming** that it is not too onerous a task for the user-mode thread
package to extract a thread from a dead activation and start it up in a
new activation, the without-warning preemption of threads by the kernel
does not seem to interfere much with the user package implementing its
threading scheme.
This archive was generated by hypermail 2.1.6 : Sat Jan 24 2004 - 20:16:55 PST