Features and characteristics of the rtmk microkernel

Described here is some features and characterists of the rtmk microkernel. Some are not yet implemented.

Preemptive Kernel

The rtmk kernel is fully preemptive, which allows it guarantee good response times. Most global kernel data structures must be protected by appropriate synchronization objects such as mutual exclusive locks (mutexes), read-write locks or spin locks. Although this is a formadable task, it is also an essential requirement for a multiprocessor operating systen.

Interrupt Threads

Interrupts are implemented using special kernel threads that can use standard synchronization primitives of the kernel and block on resources if necessary. Aa a result, rtmk rarely needs to raise the interrupt level to protect critical regions, and has only a few nonpreemptive code segments. Thus a higher-priorty thread can be scheduled as soon as it is runnable.

Interrupt threads always run at the highest priority in the system. If a interrupt threads needs to block on a resource, it can only be restared on the same processor.

Multiprocessor Support

rtmk maintains a single dispatch queue for all processors. However, some threads (such as interrupt threads) may be restricted to run on a single, specific processor. Processors can communicate with each other by sending cross-processor interrupts (also known as interprocessor interrupts).

Callouts

UNIX services all callouts at the lowest interrupt priority, which is still higher than any real-time priority. If the callout was issued by a low-priority threads, its servicing might delay the scheduling of a higher prority thread.

To solve this problem, callouts are handled by a callout thread that runs at the maximum system priority, which is lower than any real-time priority. Callouts requested by real-time threads are maintainer separately and invkoked at the lowest interrupt level, thus ensuring prompt dispatch of time-critical callouts.

Priority Inversion

The priority inversion problem refers to a situation where a lower priority thread holds a resource needed by a higher priority process, thereby blocking the higher-priority thread.

This can be solved using a technique called priority lending. When a high-priority thread blocks on a resource, it temporarily transfers (or lends) its priority to the lower-priority thread that owns the resource.

Migrating Threads

One of the shortcomings with microkernel design is that RPC is normally a pretty heavy and time-consuming operation. Since an operating system based upon a microkernel uses RPC as its main communication facility, the performance of RPC is very important.

One technique that can be used to increase performance is migrating threads; If RPC is fully visible to the kernel, an alternative model of control transfer can be implemented. Migrating threads allows threads to "move" from one task to another as part of their normal functioning. In this model, during an RPC the kernel does not block the client thread upon its RPC kernel call, but instead arranges for it to continue executing on the server's code. No service thread needs to be awakened by the kernel -- instead, for the purpose of RPC, the server is merely a passive repository for code to be executed by client threads.

Only a partial context switch is involved -- the kernel switches address space and some subset of CPU registers such as user stack pointer, but does not switch threads or priority, and never invlolves the scheduler.

Since the client thread lends its scheduling information to the server, priority inversion can be reduced.

johan rydberg Last modified: Tue Dec 18 21:55:49 CET 2001