Scheduler activations: effective kernel support for the user-level
management of parallelism
Anderson, Bershad, Lazowska, Levy
1992
Summary by Ed Swierk

Basic idea: provide kernel interface for applications to control
scheduling of kernel-level threads.

Goal: achieve the high performance and flexibility of user-level
threads with the functionality of kernel-level threads.

Three major problems with user-level threads, all due to the fact that
the kernel knows nothing about user-level threads:

* When a thread blocks due to IO or a page fault, the entire process
(or kernel-level thread) is blocked.

* With multiple threads in a single process on a multiprocessor
system, only one processor will be utilized; other processors may sit
idle even if there are many ready threads.

* In a situation where one process has high-priority threads and
another process has only low-priority threads, a high-priority thread
could wait for a processor while a low-priority thread runs.

The proposed solution is to supplement a user-level threads package
with kernel support in the form of scheduler activations.  From the
user program's point of view, the kernel provides it with a number of
processors, which can vary as the program runs.

A scheduler activation acts as a vessel for a running, user-level
thread.  The kernel creates a new activation to transfer control from
the kernel to the user-level thread on an event, such as adding a new
processor.  The user-level thread scheduler uses an activation to
execute user-level threads and to make calls back to the kernel.

Calls from the kernel to the user occur where a traditional kernel
thread scheduler would be forced to make a scheduling decision:

- add this processor (processor #)
- processor has been preempted (preempted activation # and its machine
  state)
- scheduler activation has blocked (blocked activation #)
- scheduler activation has unblocked (unblocked activation # and its
  machine state)

The user program calls the kernel whenever it has more runnable
threads than processors, or vice versa.  It does not have to call the
kernel for other thread operations, like switching context between
threads in the same process.  This is the key to the performance
advantage of scheduler activations over kernel threads, where every
thread operation involves a trap into the kernel.

Overall comments: Good idea, well executed and analyzed.  Furthers the
trend of implementing mechanism in the kernel but giving applications
control over policy, like page-replacement policy in Harty and
Cheriton 1992.