Processes and Multithreading

A computation can often be decomposed into a number of threads which belong to a single process. SPEEDOS supports this in a somewhat unconventional way. A user can create a number of processes, which are of course persistent. Since each process is held in a separate container, it can be uniquely identified by its container number. Each process can in turn be decomposed into a number of threads.

The intention of the SPEEDOS process design is that different persistent processes correspond to particular user (or business) activities (e.g. a banking process, a games process, a printing process, etc.). But these do not execute on the CPU as such. Instead each process has at least one thread (and often has more). These threads (not the processes which created them) are the actual execution units scheduled by the thread scheduler. Thus in the SPEEDOS context the issues discussed in the previous subsection (In-Process Design) refer to SPEEDOS threads (not to SPEEDOS processes). The container of a process holds inter alia a thread stack for each of its threads. Threads can also be uniquely identified via a subfield of the process number. Threads are created and can persist (even when logged out) in their parent process container.

Normally threads are associated with users, executing in-process. These are scheduled via a node-wide thread scheduler, which is a normal user level module that is only privileged in that it has capabilities allowing it to call certain kernel interfaces. The kernel activities on a node execute independently of user level threads and have higher priority. But there are a few kernel threads which exist as user-level threads. These execute and are scheduled by the thread scheduler alongside the normal user threads. Interrupts activate the kernel, which eventually re-activates the thread scheduler.