Content

[Real-Time Control System: Chapter 8]

Scheduling Theory 1. Introduction

Real-Time Systems, Lecture 12

2. Execution Time Estimation

3. Scheduling Approaches
Martina Maggio 3.1 Static Cyclic Scheduling
25 February 2020
3.2 Fixed Priority Scheduling
Lund University, Department of Automatic Control
www.control.lth.se/course/FRTN01 3.3 Earliest Deadline Scheduling
3.4 Reservation Based Scheduling

Scheduling Theory

Goal: guarantee that a set of tasks sharing resources (CPU) meet their
deadlines.
Notation: events occur (they require computations, like interrupts)
which can be separated into aperiodic (sporadic) and periodic events; a
Introduction task executes a piece of code in response to an event, the worst-case
execution time (WCET) is an upper bound to the amount of CPU time
the task execution requires (when the task is alone in the system); a
deadline is the maximum allowed time for the task completion.

Scheduling is the act of choosing which event to process at a given time

(which task to execute at a given time).

Schedulability Analysis

For hard real-time systems the deadlines must always be met. An offline
test (performed before the system is started) is required, to check that
there are no circumstances when deadlines are missed. A system is
unschedulable if the scheduler does not find a way to switch between
the tasks and meet all the deadlines.
A test can be: Execution Time Estimation
• sufficient if when the answer is yes all the deadlines are met;
• necessary if when the answer is no there really is a situation in
which deadlines are missed;
• exact if it is both sufficient and necessary.

We require a sufficient test and we would like it to be as close as

possible to necessary.

3
Execution Time Estimation Measuring Execution Time

The code is compiled and run with measuring devices (for example a
Basic question: How much CPU time does this piece of code need?
logical analyzer) connected or the operating system provides execution
Two major approaches: time measurements.
• measuring execution time; If the piece of code has input data, a large set of test input data must be
• analyzing execution time. used and the longest time required is the longest time masured plus some
safety margin.

4 5

Measuring Execution Time Measuring Execution Time

0.4
Problems:

• execution times are data dependent (for example sensor readings);

Probability

0.3
• caching (memories have different speed, a memory reference causing
a cache miss takes much longer time that one that finds the data in Longest
0.2
the cache); observed case
• pipelining and speculative execution;
0.1
• garbage collectors, etc. Used case
The general problem of this approach is that we are not guaranteed 0
that we have experienced the longest execution time. 0 2 4 6 8 10 12
Latency [s]
Best-case Worst-case

6 7

Analyzing Execution Time Analyzing Execution Time

Problem: branching statements (if, case)

we don’t know which code is executed before runtime.

Aim: a tool that takes the source code and automatically decides the MOV(_X) D0
longest execution time with formal correctness (research area the last 20 CMP D0 5 B1
if (x>5) BGT L1 if B1
years).
x=x+1; MUL D0 3 B3
Problems: compiler dependent (different compilers generate different else MOVE D0 B2 else
code, the remedy is working with the machine code). x=x*3; JMP L2 B2
Approach: use the instruction tables from the CPU manufacturer and L1: ADD D0 1 B3
add up the instruction times of the individual statements. L2: ...

Longest execution time:

time(B1) + max(time(B2), time(B3))

8 9
Analyzing Execution Time Analyzing Execution Time

Problem: branching statements (if, case)

we don’t know which code is executed before runtime.

cycles Extended to more complex statements like nested if statements.

MOV: 8
cycles(B1) = 8+4+4 = 16 if (x>0)
CMP: 4
cycles(B2) = 48+8+4 = 60 if (x>5) x = x+1;
BGT: 4
cycles(B3) = 4 else x = x*3;
MUL: 48
cycles(if) = 16 + max(60,4) = 76 else
JMP: 4
ADD: 4 x = x+10;

8MHz clock frequency, 1 cycle takes 125 ns

time(if) = 76 * 125 ns = 9.5 µs

10 11

Analyzing Execution Time Analyzing Execution Time

Problems:
Problems:
• goto: data flow difficult to find out.
• Loops (for, while): number of iterations unknown. • Caches and multi-threaded execution: with single threaded
Remedy: the programmer must annotate the source code with the applications caches can be handled well, with multi-threaded
maximum number of iterations the loop executes. application pessimistic assumption that each context switch causes
• Recursion: how deep can the recursive call get. cache misses.
Remedy: recursion not allowed.
The general problem of the approach is that it is very pessimistic. The
• Allocation of dynamic memory: unknown time for memory actual longest execution time might be substantially smaller than the
management. Difficult to handle for an analysis tool. analysis response. However, the analytical approach is the only choice to
obtain formal guarantees.

12 13

WCET Analysis Tools

Three phases:

• Flow analysis: calculate all possible execution paths in the program,

in order to limit the maximum number of times the different
instruction types can be executed.
• Low-level analysis: calculates the execution time of the instructions Scheduling Approaches
on the given hardware.
• WCET calculation: combine the previous steps.

For the uniprocessor case with simple cache structures and single
threaded applications, results are typically only 10-15% larger than the
true WCET. For multi-threaded applications or multicore platforms the
pessimism increases.

14
Notation Notation

Period

Notation Description Relative deadline

Response time
Ci Worst case execution time of task i
Ti Period of task i
Di Relative deadline of task i τ

t
PN Ci Release time Absolute deadline
CPU Utilization: U = i =1
Ti

15 16

The critical instant Scheduling Approaches

It can be shown that, in the uni-processor case, the worst situation from
a schedulability perspective occurs when all the tasks want to start their
execution at the same time instant. This is known as the critical instant.
If the task set is schedulable in this situation it will also be schedulable in • Static Cyclic Scheduling
all other situations. • Fixed Priority Scheduling
If we can show that the task set is schedulable for the worst-case • Earliest Deadline Scheduling
execution times, the task set will be schedulable if execution times are • Reservation Based Scheduling
shorter.
In uni-processor analysis, we just need to check for the worst case
execution time and the critical instant.

17 18

Static Cyclic Scheduling Static Cyclic Scheduling: Analysis

• Offline approach.
• Analysis: trivial, run through the table and check timing
• Configuration algorithm generates an execution table (or calendar)
requirements.
using many different algorithms (optimization).
• Limitations: can only handle periodic tasks, aperiodic are made
• The table repeats cyclically. The runtime dispatcher simply follows
periodic using polling; the task calendar cannot be too large
the table (sets up an hardware interrupt when a context switch
(shortest repeating cycle is the hyperperiod – the least common
should be performed, starts the first task in calendar, when the
multiple, LCM, of the task periods – example: periods 5, 10 and 20
hardware interrupt arrives the first task is preempted and the second
gives a cycle of 20, periods 7, 13 and 23 gives a cycle of 2093 – to
is run).
reduce the calendar the periods can be made shorter).
• Both preemptive and non-preemptive scheduling.

19 20
Static Cyclic Scheduling: Analysis Static Cyclic Scheduling: Example

• Advantages: a number of different constraints can be handled – for Task Name T D C

example exclusion constraints, precedence constraints. It is possible A 5 5 2
to use constraint programming to find a schedule. B 10 10 4
• Disadvantages: inflexible (static design), building a schedule is
NP-hard (potentially even if a schedule exists it can be difficult to Pn Ci 2 4
CPU Utilization: U = i =1= + = 0.8
find, good heuristic algorithms). Ti 5 10
Schedule lenght: LCM(5, 10) = 10

21 22

Static Cyclic Scheduling: Example Static Cyclic Scheduling: implementation

CurrentTime(t);
Schedule (repeat): LOOP
• from 0 to 2, task A; A();
B();
• from 2 to 6, task B;
A();
• from 6 to 8, task A; IncTime(t, 10);
• from 8 to 10, no task. WaitUntil(t);
END;
Worst case response time for task A: 3 ≤ DA
Worst case response time for task B: 6 ≤ DB
Problem: what if it only takes 2 time units to execute task B? Then A
would start before it should.

23 24

Static Cyclic Scheduling: Implementation Fixed Priority Scheduling

CurrentTime(t);
LOOP
A();
IncTime(t, 2);
WaitUntil(t); • Each task has a fixed priority.
B(); • The dispatcher selects the task with the highest priority.
IncTime(t, 4); • Preemptive.
WaitUntil(t); • Used in most real-time kernels and real-time operating systems.
A();
IncTime(t, 4);
WaitUntil(t);
END;

25 26
Fixed Priority Scheduling: Rate Monotonic Fixed Priority Scheduling: Rate Monotonic analysis

Model:

• Rate Monotonic is a scheme for assigning priorities to tasks. • Periodic tasks,

• Priorities are set monotonically with rate. • Di = T i ,
• A task with a shorter period is assigned a higher priority. • Tasks are not allowed to be blocked or to suspend themselves,
• Introduced in C.L. Liu and J.W. Layland, Scheduling Algorithms for • Priorites are unique,
Multiprogramming in a Hard Real-Time Environment, JACM, Vol. • Task execution times bounded by Ci ,
20, Number 1, 1973. • Task utilization Ui = Ci
,
Ti
• Interrupts and context switches take zero time.

27 28

Fixed Priority Scheduling: Rate Monotonic analysis Fixed Priority Scheduling: Rate Monotonic analysis

Result:

• If the task set has a utilization below a utilization bound then all
deadlines will be met. Since 1973 the models have become more flexible and the analysis better;
n
X Ci M. Joseph and P. Pandaya, Finding Response Times in a Real-Time
U= ≤ n(21/n − 1) System, The Computer Journal, Vol. 29, No. 5, 1986.
Ti
i =1
Notation:
Sufficient condition (if the utilization is larger than the bound, the task
Notation Description
set may still be schedulable).As n → ∞ the utilization bound tends to
0.692 (log 2). Ci Worst-case execution time of task i
If the CPU utilization is less than 69% all the deadlines are met. Ti Period of task i
Alternative (tighter) test – Hyperbolic Bound: Di Relative deadline of task i
Ri Worst-case response time of task i
n
Y Ci
( + 1) ≤ 2
Ti
i =1

29 30

Fixed Priority Scheduling: Rate Monotonic analysis Fixed Priority Scheduling: Rate Monotonic analysis

Scheduling test: Ri ≤ Di (necessary and sufficient)

Model:
X  Ri 
Di ≤ T i , Ri = Ci + Cj Limitations of the exact analysis: if the response time is larger than the
Tj
∀j∈hp(i ) period then the quantitative value cannot be trusted
where hp(i) is the set of tasks of higher priority than task i. The function
• Reason: The analysis does not take interference from previous jobs
⌈x⌉ is the ceiling function that returns the smallest integer ≥ x.
of the same task into account.
Recurrence relation, solved by iteration. The smallest solution is searched
for. • More advanced analysis exists.

However, one still knows that the deadline will not be met, which is
X Rn 
Rin+1 = Ci + i
Cj normally what one is interested in.
Tj
∀j∈hp(i )

Start with Ri0 = 0.

31 32
Fixed Priority Scheduling: Rate Monotonic analysis Fixed Priority Scheduling: Rate Monotonic example

Task name T D C Priority

Best-case response time: A 52 52 12 low
Under rate-monotonic priority assignment one can also calculate the B 40 40 10 medium
best-case response time Rib of a task i. C 30 30 10 hight
Original (approximative) analysis:
X  R b − Tj 
Rib = Cimin + i
Cjmin P3 Ci
Tj i =1 = 0.814.
∀j∈hp(i ) 0 Ti
1/3
3(2 − 1) = 0.7798. Using this analysis we cannot say if the task set is
where Ciminis the best-case execution time of the task and
schedulable or not.
⌈x⌉0 = max(0, ⌈x⌉).
Hyperbolic bound:
Can be used to calculate the worst-case input-output latency of a control Q3 Ci
task. i =1 ( + 1) = 2.0508 (not ≤ 2). Using this analysis we cannot say if
Ti
the task set is schedulable or not.

33 34

Fixed Priority Scheduling: Rate Monotonic example Fixed Priority Scheduling: Rate Monotonic example
Task name T D C Priority
Task C has highest priority → will not be interrupted and hence
A 52 52 12 low
RC = CC = 10 (RC1 )
B 40 40 10 medium
C 30 30 10 hight Task B has medium priority. The response time will be at least equal to
CB = 10 (RB1 ). During that time B will be interrupted once by C.
Exact analysis:
Hence, the response time will be extended by the execution time of C,
0 1 2
RC = 0, RC = CC = 10, RC = CC = 10 i.e. RB2 = 10 + 10 = 20. During this time B will only be interrupted once
RB0 = 0, RB1 = CB = 10, by C and that has already been accounted for, i.e. RB3 = 20.
 
2 10
RB = CB + CC = 20,
TC Task A has lowest priority. The response will be at least equal to
RB3 = . . . = 20 CA = 12 (RA1 ). During that time A will be interrupted once by C and
RA0 = 0, RA1 = CA = 12, once by B, i.e., RA2 = 12 + 10 + 10 = 32. During this time A will be
   
2
RA = CA +
12
CB +
12
CC = CA + CB + CC = 32 interrupted twice by C and once by B, i.e., RA3 = 32 + 10 = 42. During
TB TC
this time A will be interrupted twice by C and twice by B, i.e.,
RA3 = . . . = 42, RA4 = . . . = 52, RA5 = . . . = 52
RA4 = 42 + 10 = 52. During this time no more unaccounted for interrupts
Ri ≤ Di ⇒ schedulable will occur, i.e., RA5 = 52.

35 36

Fixed Priority Scheduling: Deadline Monotonic Fixed Priority Scheduling: Deadline Monotonic analysis

• The rate monotonic policy is not very good when D ≤ T .

• An infrequent but urgent task would still be given a low priority. For a system with n tasks, all tasks will meet their deadlines if the sum
• The deadline monotonic ordering policy works better. over all tasks of the ratio between the worst-case execution time of the
task and the deadline of the task is below a certain bound.
• A task with a short relative deadline D gets a high priority.
n
X
• This policy has been proved optimal when D ≤ T (if the system is Ci
≤ n(21/n − 1)
unschedulable with the deadline monotonic ordering then it is Di
i =1
unschedulable with all other orderings).
• With D ≤ T we can control the jitter in control delay.

37 38
Fixed Priority Scheduling: Deadline Monotonic analysis Fixed Priority Scheduling: Extension – the blocking problem

How should interprocess communication be handled.

The analysis up to now does not allow tasks to share data under mutual
Exact Analysis: exclusion constraints (e.g. no semaphores or monitors)
The response time calculations from the rate monotonic theory is also
Main problem:
applicable to deadline monotonic scheduling. Response time calculation
does not make any assumptions on the priority assignment rule. • a task i might want to lock a semaphore,
but the semaphore might be held by a lower priority task;
• task i is blocked.

39 40

Fixed Priority Scheduling: Extension – the blocking problem Fixed Priority Scheduling: Further extensions

The blocking factor, Bi is the longest time a task i can be delayed by the
execution of lower priority tasks

X  Ri 
Ri = Ci + Bi + Cj
Tj • Release Jitter: the difference between the earliest and latest release
∀j∈hp(i )
of a task relative to the invocation of the task;
Priority inversion may cause unbounded blocking time if ordinary locks • Context Switch Overheads;
are used.
• Clock Interrupt Overheads;
Different locking schemes have different blocking times: • Distributed systems using CAN.
• ordinary priority inheritance;
• priority ceiling protocol;
• immediate inheritance protocol.

41 42

Fixed Priority Scheduling: Overrun behavior Earliest Deadline First (EDF) Scheduling

• Dynamic Approach: all scheduling decisions are made online.

• Overrun means exceeding the worst-case execution time. • The task with the smallest absolute deadline runs.
• With fixed priority schemes, this will only affect the current task and • Preemptive.
lower priority ones. These tasks can miss deadlines and/or not get • Ready-queue sorted in deadline order.
any execution time at all. Higher priority tasks are unaffected. • Dynamic priorities. It is more intuitive to assign deadlines to tasks
than priorities. Requires only local knowledge.

43 44
Earliest Deadline First (EDF) Scheduling: analysis Earliest Deadline First (EDF) Scheduling: analysis

Simplest Model: Result:

• Periodic Tasks, • If the utilization U of the system is not more than 100% then all the
deadlines are met.
• Each task i has a period Ti , a worst-case computation time Xn
Ci
requirement Ci and a relative deadline Di , U= ≤1
Ti
i =1
• Tasks are independent,
Necessary and sufficient condition. Advantage: the processor can be fully
• The kernel is ideal,
used. Less restrictive assumptions make the analysis harder (see RTCS
• Di = T i .
for the analysis in the case Di ≤ Ti ).

45 46

Earliest Deadline First (EDF) Scheduling: example Earliest Deadline First (EDF) Scheduling: example

Task name T D C Task name T D C

A 8 8 1 A 8 8 1
Utilization: 1/8 + 2/5 + 4/10 = 0.925 Utilization: 1/8 + 2/5 + 4/10 = 0.925
B 5 5 2 B 5 5 2
C 10 10 4 C 10 10 4

A A

B B

C C
t t
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

47 47

Earliest Deadline First (EDF) Scheduling: example Earliest Deadline First (EDF) Scheduling: example

Task name T D C Task name T D C

A 8 8 1 A 8 8 1
Utilization: 1/8 + 2/5 + 4/10 = 0.925 Utilization: 1/8 + 2/5 + 4/10 = 0.925
B 5 5 2 B 5 5 2
C 10 10 4 C 10 10 4

A A

B B

C C
t t
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

47 47
Earliest Deadline First (EDF) Scheduling: example Earliest Deadline First (EDF) Scheduling: example

Task name T D C Task name T D C

A 8 8 1 A 8 8 1
Utilization: 1/8 + 2/5 + 4/10 = 0.925 Utilization: 1/8 + 2/5 + 4/10 = 0.925
B 5 5 2 B 5 5 2
C 10 10 4 C 10 10 4

A A

B B

C C
t t
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

47 47

Earliest Deadline First (EDF) Scheduling: example Earliest Deadline First (EDF) Scheduling: example

Task name T D C Task name T D C

A 8 8 1 A 8 8 1
Utilization: 1/8 + 2/5 + 4/10 = 0.925 Utilization: 1/8 + 2/5 + 4/10 = 0.925
B 5 5 2 B 5 5 2
C 10 10 4 C 10 10 4

A A

B B

C C
t t
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

47 47

Earliest Deadline First (EDF) Scheduling: example Earliest Deadline First (EDF) Scheduling: example

Task name T D C Task name T D C

A 8 8 1 A 8 8 1
Utilization: 1/8 + 2/5 + 4/10 = 0.925 Utilization: 1/8 + 2/5 + 4/10 = 0.925
B 5 5 2 B 5 5 2
C 10 10 4 C 10 10 4

A A

B B

C C
t t
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

47 47
Earliest Deadline First (EDF) Scheduling: example Earliest Deadline First (EDF) Scheduling: example

Task name T D C Task name T D C

A 8 8 1 A 8 8 1
Utilization: 1/8 + 2/5 + 4/10 = 0.925 Utilization: 1/8 + 2/5 + 4/10 = 0.925
B 5 5 2 B 5 5 2
C 10 10 4 C 10 10 4

A A

B B

C C
t t
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

47 47

Earliest Deadline First (EDF) Scheduling: example Earliest Deadline First (EDF) Scheduling: example

Task name T D C Task name T D C

A 8 8 1 A 8 8 1
Utilization: 1/8 + 2/5 + 4/10 = 0.925 Utilization: 1/8 + 2/5 + 4/10 = 0.925
B 5 5 2 B 5 5 2
C 10 10 4 C 10 10 4

A A

B B

C C
t t
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

47 47

Earliest Deadline First (EDF) Scheduling: overrun behavior Earliest Deadline First (EDF) Scheduling: summary

In the case of overrun all tasks will be affected, so they may all miss
deadlines (there is a “domino” effect). However, in general EDF is more Also for EDF there exists a very well-developed schedulability theory.
fair than priority-based scheduling – the available resources are Resource access protocols similar to priority inheritance and ceiling.
distributed among all the tasks.

48 49
Reservation Based Scheduling Reservation Based Scheduling: static and dynamic

If a tasks overruns (executes longer than anticipated) this will effect Use static cyclic scheduling for some tasks and let the other tasks be
other tasks negatively. priority-based (event-based) which only may execute during the idle
• In priority-based systems the priority decides which tasks that will be periods of the static schedule.
effected. Used in Rubus from Arcticus:
• In deadline-based systems all tasks will be effected.
• swedish RTOS used by Volvo,
We want to provide temporal protection between tasks that guarantees • red threads - statically scheduled,
that a certain task or group of tasks receives a certain amount of the • blue threads - dynamically scheduled.
CPU time.

50 51

Reservation Based Scheduling: priority-based systems Reservation Based Scheduling: priority-based systems

How can, conceptually, a reservation-based scheduling system be

implemented on top of ordinary priority-based scheduling. Each task or
task set receives a certain percentage of the CPU. (50% + 30% + 20%). Each task set gets exactly its share of the CPU.
Can be viewed as if the tasks are executed on a correspondingly much The scheduler can be viewed as consisting of as many ready-queues as
slower CPU. there are reservation sets.
Two variants: An external timer is set up to generate interrupts when it is time to
switch which ready-queue that is active.
• Each task set gets exactly its share of the CPU;
• Each task set gets at least its share of the CPU. One idle process in each ready-queue.

Question: Over which time horizon does the CPU reservation hold?

52 53

Reservation Based Scheduling: priority-based systems Reservation Based Scheduling: SCHED DEADLINE

In Mainline Linux Kernel since 2 Feb 2014 17:12:22 (Linux 3.14.2).

Each task set gets at least its share of the CPU.
One ready-queue.
Make sure that the tasks belonging to the currently serviced task set all
have higher priority than the tasks in the tasks sets which are not
serviced.
An external timer is set up to generate interrupts when it is time to
switch between the tasks sets.
Lower the priorities of the the tasks that have been serviced and raise the
priorities of the tasks that should be serviced.
A single idle task.

54 55
Reservation Based Scheduling: Industrial practice More Information

A nice introduction and overview of the state-of-the-art in uni-processor

scheduling of real-time systems can be found in:
Beginning to emerge in commercial RTOS.
“Real Time Systems by Fixed Priority Scheduling” by Ken Tindell and
Integrity from Green Hills Software Inc. Hans Hansson, Dept. of Computer Systems, Uppsala University
http://www.docs.uu.se/˜hansh/fpsnotes-9710.ps

56 57