MigratingThreads

[thread-migrate.pdf]

The key element of our design is decoupling of the thread abstraction into the execution context and the schedulable thread of control, consisting of a chain of contexts. A key element of our implementation is that threads are now "based" in the kernel, and temporarily make excursions into tasks via upcalls.

• Thread - a sequential flow of control.
• Single process - single kernel-provided thread (traditional Unix).
• Single task - multiple kernel-provided threads (Mach).
• User threads - provided by user-level libraries on top of kernel threads, by manipulation of PC and stack from user-space.

In many systems, a thread includes much more than the flow of control. In Mach, a thread also:

• is a schedulable entity, with priority and scheduling policy attributes.
• contains resource accounting statistics (e.g. accumulated CPU time).
• contains execution context of a computation - state of registers, PC, SP, references to containing task and designated exception handler.
• provides the point of thread control, visible to user programs through a thread control port.

During migrating threads RPC:

• only partial context switch (PD and subset of registers, like stack pointer),
• scheduler is never involved.
• there's no server thread state (registers, stack) to restore at all.

Note that binding in this model can be very similar to that in thread switching (static) model [Section 6.2] <-#DFN

Changes to Mach model:

Thread decoupled into:

• logical flow of control, represented by stack of activations in tasks; (per-space UTCB)
• schedulable entity, with priority and resource accounting. (in-kernel KTCB)

Activation represents:

• execution context of a computation, including a task whose code it is executing, its exception handler, PC, registers and SP
• user-visible point of control.

Activation is now exported to user-code as "thread". This is necessary to provide controllability and protection at the same time. "Thread" migrates between tasks and enters and leaves the kernel. "Activation", a user-mode part, remains permanently fixed to a particular task. Arbitrary control is permitted only on a specific activation, but not the thread as a whole.

Clouds [16]

"Scheduler activations"[1] - kernel threads with special support for user-level scheduling (primarily concerned with behavior of kernel threads within a PD, orthogonal to this paper). Theoretically could be combined in the same system.

In an object-based environment, invocation of relatively fine-grained objects is prohibitively inefficient if all objects must be active.

[@sa GlueCode.md]

Termination mechanism used (splicing up activations at the point of termination and letting the upper half continue work, while the original thread returns to the previous activation) required careful planning of kernel data structures and locking mechanisms, in particular, the line between the kernel and glue code had to be defined precisely. Once worked out, this technique not only added additional controllability, but considerably simplified the implementation of control mechanisms in the kernel.

temporary mapping [23]

thread migrations to other nodes researched in depth in Alpha [11]

@todo biblio:

[11] Raymond K. Clark, E. Douglas Jensen, and Franklin D. Reynolds. An architectural overview of the Alpha real-time distributed kernel. In Proc. of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 127-146, Seattle, WA, April 1992. [AlphaRtDistributedKernel.pdf]

• protothreads
• above kernel threads a userspace scheduling system like Grand Central Dispatch/Dryad can be used.