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.

Enabling scalability and performance in a large scale CMP environment

“…Several operating systems have explored issues related to performance and scalability on multi-processor platforms [1][17] [18][19] [20]. While the McRT framework is similar in spirit to these projects and learnt from their experiences, it is more lightweight and had to address significant differences in the underlying hardware.…”

Real-time Java and multi-core architectures

“…In general, the lock holder preemption problem can be solved either by prevention-or recovery-based solutions ( [3,18]). Prevention-based solutions notify user-level threads about imminent preemption.…”

Scheduling for Locality in Shared-Memory Multiprocessors

“…" Trends in operating system research suggest that most of the resource allocation and process management software should be moved out of the operating system kernel [46,4,53], and implemented in user-level servers instead. The operating system only provides the basic mechanisms to tie the system together.…”

“…Several studies have shown that this effect can lead to severe performance degradation [45,48,49,721. For this reason, some systems incorporate a special mechanism to avoid preemption while in a critical section [4, 28,53] In addition, Squillante and Lazowska [66,67] have shown that by ignoring the affinity 0 that may have been created between a process and a processor, a centralized ready queue can introduce a performance penalty close to a factor of two This penalty is attributed to cache reload costs and increased bus traffic and contention overheads. They propose a scheduling mechanism that avoids migrating processes unless significant imbalance occurs.…”

“…The operating system we used in our experiments on the Butterfly, Psyche (53,62,63]. implements a straightforward extension of uniprocessor time-slicing.…”