Page 129 - DCAP103_Principle of operating system

Principles of Operating Systems

Notes Therefore, the time to get back to the scheduler may vary by a few instructions (insignificant for
a 60 Hz scheduler), but will always be short and bounded. It is much more difficult to engineer
a kernel that has preemptible system calls in this manner, which is why most kernels do not
do it this way.
4.4.9 Bounded Execution Times

In order to allow computation of the overhead of system calls that a thread will execute while
doing its work, an RTOS should provide bounded execution times for all such calls. Two major
problems involve the timing of message transfers and the timing of mutex take operations.
A thread may spend time performing a variety of activities of course, its primary activity is
executing code. Other activities include sending and receiving messages. Message transfer times
vary with the size of the data. How can the system designer account for this time? The RTOS can
provide a capability for controlling whether transfer times are attributed to the sending thread
or to the receiving thread, or shared between them. Indeed, the kernel’s scheduler should treat
all activities, not just the primary activity, as prioritized units of execution so that the system
designer can properly control and account for them.
4.4.10 Priority Inversion

Priority inversion has long been the bane of system designers attempting to perform rate
monotonic analysis, since RMA depends on higher priority threads running before lower priority
threads. Priority inversion occurs when a high priority thread is unable to run because a mutex
(or binary semaphore) it attempts to obtain is owned by a low priority thread, but the low
priority thread is unable to execute and release the mutex because a medium priority thread is
also runnable. The most common RTOS solution to the priority inversion problem is to support
the priority inheritance protocol.

Figure 4.6: Priority Inversion

H

M

L

A mutex that supports priority inheritance works as follows—if a high priority thread attempts
to take a mutex already owned by a low priority thread, the kernel automatically elevates the
low priority thread to the priority of the high priority thread. Once the low priority thread
releases the mutex, its priority will be returned to normal and the high priority thread will
run. The dynamic priority elevation prevents a medium priority thread from running while the
high priority thread is waiting; priority inversion is avoided. In this example, the critical section
execution time (the time the low priority thread holds the mutex) is added to the overhead of
the high priority thread.

122 LOVELY PROFESSIONAL UNIVERSITY