Page 128 - DCAP103_Principle of operating system

Unit 4: Process Management-III

Although not specified in ARINC 653, a prudent addition to the implementation is to apply Notes
the concept of a background partition. When there are no runnable threads within the active
partition, the partition scheduler should be able to run background threads, if any, in the
background partition, instead of idling. An example background thread might be a low
priority diagnostic agent that runs occasionally but does not have hard real-time deadlines.
Attempts have been made to add partition scheduling on top of commercial off-the-shelf
operating systems by selectively halting all the threads in the active partition and then
running all the threads in the next partition. Thus, partition switching time is linear with
the number of threads in the partitions, an unacceptably poor implementation.

The RTOS must implement the partition scheduler within the kernel and
ensure that partition switching takes constant time and is as fast as possible.

4.4.7 Schedulability
Meeting hard deadlines is one of the most fundamental requirements of a real-time operating
system and is especially important in safety-critical systems. Depending on the system and the
thread, missing a deadline can be a critical fault.

Rate monotonic analysis (RMA) is frequently used by system designers to analyze and predict
the timing behavior of systems. In doing so, the system designer is relying on the underlying
operating system to provide fast and temporally deterministic system services. Not only must
the designer understand how long it takes to execute the thread’s code, but also any overhead
associated with the thread must be determined. Overhead typically includes context switch time,
the time required to execute kernel system calls, and the overhead of interrupts and interrupt
handlers firing and executing.
All real-time operating systems incur the overhead of context switching. Lower context switching
time implies lower overhead, more efficient use of available processing resources, and increased
likelihood of meeting deadlines. A real-time operating system’s context switching code is usually
hand optimized for optimal execution speed.
4.4.8 Interrupt Latency

A typical embedded system has several types of interrupts resulting from the use of various
kinds of devices. Some interrupts are higher priority and require a faster response time than
others. For example, an interrupt that signals the kernel to read a sensor that is critical to an
aircraft’s flight control should be handled with the minimum possible latency. On the other
hand, a typical timer tick interrupt frequency may be 60 Hz or 100 Hz. Ten milliseconds is an
eternity in hardware terms, so interrupt latency for the timer tick interrupt is not as critical as
for most other interrupts.
Most kernels disable all interrupts while manipulating internal data structures during system
calls. Interrupts are disabled so that the timer tick interrupt cannot occur (a timer tick may cause
a context switch) at a time when internal kernel data structures are being changed. The system’s
interrupt latency is directly related to the length of the longest critical section in the kernel.
In effect, most kernels increase the latency of all interrupts just to avoid a low priority timer
interrupt. A better solution is to never disable interrupts in kernel system calls and instead
to postpone the handling of an intervening timer tick until the system call completes. This
strategy depends on all kernel system calls being short (or at least that calls that are not short
are restartable), so that scheduling events can preempt the completion of the system call.

LOVELY PROFESSIONAL UNIVERSITY 121