Download cubeos a component-based operating system for autonomous systems

2.1. OPERATING SYSTEMS
53
execute it on behalf of the user program, e.g. read a data block from an I/O device. Until the
device responds, the kernel would pass CPU control on to a different task that is ready to run.
After the disk hardware read the data block and put it in a buffer memory, it would inform its
driver (e.g. via a hardware interrupt). Then, the CPU would pass control back to the kernel,
again saving the context of the currently executing task. The kernel would then copy the data
from the disk buffer into the address space of the task executing the system call and pass the
CPU control back to the calling process.
This way of handling API calls is very useful if there are many threads in the system that are
mainly I/O bound, that is waiting for external hardware to execute functions. This is often
the case in server systems that service multiple users such as database or web servers. Also,
the scheduling is non-critical in this application domain since there are hardly any threads
competing for CPU time since most of them are blocked by waiting for I/O. Therefore, the
time quantum for UNIX-like systems can be large. Usually, a thread can keep the CPU for as
long as 250 milliseconds[BC00] without any performance degradation visible to the user.
Scheduling in UNIX is trying to evenly distribute CPU time to different processes. Therefore,
the priority of a process in the UNIX scheduler is often dynamic, depending on the amount
of CPU time that a process had in the past, i.e. a process that didn’t get the CPU for a long
time gets its priority increased whereas a process that used the CPU for a long time gets a
lower priority. This has clear advantages for server applications, i.e. no process can “starve”,
not getting the CPU for an extended period of time but it is also hard to determine the exact
realtime response time of such a scheduler since it depends on the runtime history of all tasks.
Therefore, when UNIX-like systems are used in realtime applications, the scheduler is usually
extended with a special class of realtime processes that have static priorities[CHO] that are not
changed over time.
2.1.2 Micro-kernel and modular operating systems
The kernel modules in monolithic operating systems such as the UNIX kernel allow the extension of these kernels in clearly defined domains, i.e. a new driver can be added.
However, some internal kernel functions cannot be extended in such an easy way. I.e. it is not
possible to replace the scheduler or the memory management of the kernel in this way, since
the changes necessary are widespread all over the kernel.
Micro-kernel operating systems try to solve this problem by implementing only minimal functions in the kernel itself, such as basic multi-threading and inter-process communication and
implementing everything else as modules, including networking, scheduling and memory management. If possible, these modules are implemented as separate processes that communicate
with each other through the microkernel IPC API. Another advantage is that these separate processes have their own memory segment and stack, so they are protected from each other and in
case of a programming error, only one module fails and the rest of the kernel stays intact.