Multitasking in Oberon System Instrumentation
Synopsis. Multitasking helps achieve smooth operation of the instrument running Oberon System. In this section I will outline how the Oberon System is implementing this essential feature.
Motivation. Since we are aiming at efficient implementation of interactive instruments powered by the Oberon System, we need to make use of its multitasking capabilities.
Background information. Multitasking permits a single core instrument to concurrently perform a few major tasks, such as the data collection and interaction with the user. There are two kinds of multitasking, preemptive and cooperative. The preemptive multitasking requires careful consideration of many "what if" questions, because any task can be interrupted at any time, and almost anything can happen between the interruption and resumption of the task. Common resources need to get locked by the running preemptible tasks in order to avoid resource corruption by other tasks. Improper resource locking can lead to either deadlocks or starvation, making life interesting for the system developers. The actual development schedules get stretched accordingly.
Cooperative multitasking. In contrast, the cooperative multitasking described in Chapter 3 of the Oberon System book stipulates, that the procedure comprising the task runs from BEGIN till the END and nothing unexpected happens in between. What the programmer writes is what the programmer gets when the task is running. This approach simplifies system programming quite a bit. As stated on page 28 of the book: Locks of common resources are completely dispensable and deadlocks are not a topic.
Foreground tasks and background tasks. The Oberon tasks are divided into the interactive foreground tasks and the non-interactive background tasks. The interactive tasks are performing some visual actions on screen. They are meant to implement some sort of interaction with the operator, like for example scrolling a page of text. The non-interactive background tasks correspond to batch jobs known from other operating systems.
Background tasks are implemented with commands. The Oberon background task is synonymous with a command being called from the main system loop. The command gets installed in the loop with an optional specification, how often it should get called by the system. Calling the command is thus increasing the loop execution time by how long it takes to execute the command. This is introducing a practical recommendation that the command execution should be swift. For example, the command can possibly invert a 3x3 matrix, but it should refrain from inverting a 1000x1000 one. The latter operation needs be broken into incremental steps, if it is going to be implemented in the form of the Oberon background task.
Time triggered multitasking and software reliability. The above concept is closely related to the time-triggered_architecture used to develop safety-critical aerospace and related systems. While Oberon System makes no claim to this level of safety, its architecture is in fact getting close thanks to avoidance of unexpected conditions due to preemption. This aspect of Oberon System warrants further development and scrutiny.
Summary. Oberon System implements a cooperative multitasking model, providing assurance and comfort to a system programmer. What the programmer writes is what the programmer gets when the task is running. Nothing unexpected can happen during the task execution because there is no preemption of the running task. The cooperative multitasking machinery is both frugal and very efficient. A well performing interactive instrument can be developed with a very reasonable programming effort.