Features and characteristics of the rtmk microkernel
Described here is some features and characterists of the rtmk microkernel.
Some are not yet implemented.
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.
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.
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).
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.
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
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.
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.
Last modified: Tue Dec 18 21:55:49 CET 2001