First-class user-level threads

Abstract

It is often desirable, for reasons of clarity, portability, and efficiency, to write parallel programs in which the number of processes is independent of the number of available processors. Several modern operating systems support more than one process in an address space, but the overhead of creating and synchronizing kernel processes can be high. Many runtime environments implement lightweight processes (threads) in user space, but this approach usually results in second-class status for threads, making it difficult or impossible to perform scheduling operations at appropriate times (e.g. when the current thread blocks in the kernel). In addition, a lack of common assumptions may also make it difficult for parallel programs or library routines that use dissimilar thread packages to communicate with each other, or to synchronize access to shared data.We describe a set of kernel mechanisms and conventions designed to accord first-class status to user-level threads, allowing them to be used in any reasonable way that traditional kernel-provided processes can be used, while leaving the details of their implementation to userlevel code. The key features of our approach are (1) shared memory for asynchronous communication between the kernel and the user, (2) software interrupts for events that might require action on the part of a user-level scheduler, and (3) a scheduler interface convention that facilitates interactions in user space between dissimilar kinds of threads. We have incorporated these mechanisms in the Psyche parallel operating system, and have used them to implement several different kinds of user-level threads. We argue for our approach in terms of both flexibility and performance.

Composable scheduler activations for Haskell

“…Similar to scheduler activations, Psyche [18] allows user-level threads to install event handlers for scheduler interrupts and implement the scheduling logic in user-space. Unlike these works, our system utilises scheduler activations in the language runtime rather than OS kernel.…”

Preemption Adaptivity in Time-Published Queue-Based Spin Locks

“…Finally, several researchers have suggested operating system mechanisms that provide user applications with a limited degree of control over scheduling, allowing them to avoid [4,5,14,19,25] or recover from [1,2,31,33] inopportune preemption. Commercial support for such mechanisms, however, is neither universal nor consistent.…”

“…Level II and III APIs are generally confined to research systems [1,4,19]. The Mach scheduler [2] provides a variant of the Level III API that includes a directed yield of the processor to a specified thread.…”

Extending the Chorus micro-kernel to support continuous media applications

“…In the implementation of the shared memory area, each kernel thread (referred to as a virtual processor) has an associated context structure [7] which contains information such as current user thread context, next runnable thread, global deadline and next asynchronous event time value. Each context is mapped into kernel space and used to exchange/share information with the kernel, thus avoiding unnecessary system calls.…”

“…Scheduler activations would solve this problem by injecting a new execution context whenever the actor's kernel thread blocks (but at the expense of an undesirable increase in kernel level concurrency as discussed above). Our favoured solution is to employ non blocking system calls [7]. These calls return immediately and thus allow the calling kernel thread to resume acting as a virtual processor for user level threads (the result of the call will eventually be notified by a software interrupt as discussed above).…”