Skip to content
Operating Systems

Real-time systems: EDF, rate monotonic and response time

Periodic tasks, the utilisation condition proved, optimal EDF, the Liu and Layland bound, response time analysis with an example, priority inversion and inheritance, RTOS.

In a real-time system a correct but late result is wrong: a car’s brake command, a motor controller, a pacemaker must respond within a deadline. What counts is not average speed, but the worst-case guarantee. In this lesson we look at the periodic task model, EDF scheduling with the proof of the necessary condition, rate monotonic priority with its bound and exact response time analysis worked through an example, priority inversion and real-time operating systems.

The periodic task model

We distinguish hard systems, where missing a deadline is a failure (flight control, airbags), and soft ones, where only quality degrades (video playback). Many control tasks are periodic (Digital Control lesson on implementation): task \tau_i is released every T_i, requires at most C_i of computation (the worst-case execution time) and must finish before the next release. Its utilisation factor is U_i = C_i/T_i, and the total utilisation U = \sum_iU_i.

Earliest deadline first

The EDF (earliest deadline first) algorithm runs at each instant the ready task with the nearest deadline, with preemption.

Theorem. On one processor, a set of periodic tasks with deadline equal to period is schedulable by any algorithm only if U \le 1; with EDF the condition is also sufficient.

Proof of necessity. Consider the interval [0, H), where H is the least common multiple of the periods. Task \tau_i is released H/T_i times and requires in all (H/T_i)C_i of computation, which must be done within H. The total demand is \sum_i(H/T_i)C_i = UH, and the processor offers at most H: we need UH \le H, i.e. U \le 1. ∎

Sufficiency for EDF (Liu and Layland, 1973) is proved by showing that, if a deadline were missed, in the preceding interval the processor would always have been busy with tasks with no later deadlines, and their demand would exceed the length of the interval, i.e. U \gt  1. EDF is therefore optimal: it uses the processor up to 100 %.

Rate monotonic priority and response time

Many systems use fixed priorities instead, simpler and more predictable under overload: with the rate monotonic rule (RMS) the task with the shortest period has the highest priority. Liu and Layland proved that RMS guarantees the deadlines if

    \[ U \le n\left(2^{1/n} - 1\right) \]

where n is the number of tasks: 0.83 for two, 0.78 for three, tending to \ln 2 \approx 0.69. The condition is only sufficient; for an exact answer the worst-case response time is computed, which occurs when all tasks are released together. For task i, with higher-priority tasks j:

    \[ R_i = C_i + \sum_{j}\left\lceil\frac{R_i}{T_j}\right\rceil C_j \]

because during R_i each higher-priority task is released \lceil R_i/T_j\rceil times and each time interrupts it for C_j. The equation is solved by iteration starting from R_i = C_i, until the value stops changing; the task meets its deadline if R_i \le T_i.

Rate monotonic scheduling of three tasks
Task tau 1 (period 4, computation 1) has the highest priority, tau 2 (period 6, computation 2) medium, tau 3 (period 12, computation 3) the lowest. The arrows mark the releases; the rectangles the executions. Tau 3 is interrupted twice and finishes at time 10, before its deadline at 12.

Example. Three tasks (C, T): (1, 4), (2, 6), (3, 12), with U = 0.25 + 0.33 + 0.25 = 0.83, above the 0.78 bound: the sufficient test is inconclusive. Response time of \tau_3: start from R = 3; then 3 + \lceil 3/4\rceil + 2\lceil 3/6\rceil = 6; then 3 + 2 + 2 = 7; then 3 + \lceil 7/4\rceil + 2\lceil 7/6\rceil = 3 + 2 + 4 = 9; then 3 + 3 + 4 = 10; then 3 + \lceil 10/4\rceil + 2\lceil 10/6\rceil = 3 + 3 + 4 = 10, stable. R_3 = 10 \le 12: the set is schedulable, as the figure shows.

Priority inversion

A high-priority task H waits for a lock held by a low-priority task L. If meanwhile a medium-priority task M is released, which does not use the lock, M preempts L, and H stays blocked for the whole duration of M: a less important task indirectly delays the most important one, for an unbounded time if there are many medium tasks. This is priority inversion. In 1997 the Mars Pathfinder probe kept resetting for this reason, until the priority inheritance option was enabled from Earth: while L holds a lock requested by H, L temporarily inherits H’s priority, M cannot preempt it, and H’s blocking lasts at most as long as L’s critical section. The priority ceiling protocol does more, and also prevents deadlocks between locks.

Real-time operating systems

A real-time operating system (RTOS) offers preemptive priority schedulers, small and above all bounded interrupt latencies, synchronisation tools with priority inheritance and predictable memory allocation. On microcontrollers very small kernels such as FreeRTOS or Zephyr are used, a few kilobytes in size; in larger systems Linux with the PREEMPT_RT extensions, which make almost the whole kernel preemptible and bring worst-case latencies down to tens of microseconds. The worst-case execution time C_i must be measured or computed with analysis tools, taking caches and interrupts into account: it is often the hardest part of the design.

Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x
()
x