Real-Time Operating

System
Antonio Sgorbissa

Reference Book:
Buttazzo, Giorgio C., Hard Real-time Computing
Systems: Predictable Scheduling Algorithms and
Applications, Springer-Verlag, 2009
 Introduction

 Real-time operating systems are systems in which the

correctness of the functioning depends:
 not only on the validity of results;
 but also on temporal factors, i.e., when results are produced.
 Introduction
 Control of chemical and nuclear plants
 Flight control systems
 Communication systems
 Space missions
 Industrial Automation and Robotics
 Multimedia
 Introduction
 We mostly consider the case that all tasks of interests are scheduled on a single
processor (possibly using industrial standards)
 Example: HW/SW architecture of a robot.
 The robots may have many sensors and actuators, each handled by a
dedicated microprocessor.
 We focus on the main processor that receives all data from sensors,
performs different activities and possibly sends output to actuators.
 Introduction
 The majority of real-time applications is still designed using
empirical techniques: the problems related to the handling of
temporal events is faced through
 Usage of timers or techniques for handling other events;
 Optimization of the code;
 Low-level driver for handling devices;
 Manual assignment of priorities to processes and interrupts.

OR simply IGNORED
 Introduction
 Drawbacks:
 In all the solutions above, efficiency and reliability depend on the skill
of the programmer;
 the code is difficult to understand;
 the code is hard to maintain;
 it is difficult to verify in advance if temporal constraints will be met.
 Introduction
 Software testing is not sufficient to guarantee that the system
works correctly:
 In control application, the execution flow heavily depends on the input
data;
 More accurate design techniques are required, possibly including a
statical analysis of the code and mechanisms for explicitly handling
temporal constraints;
 The system must be designed to work even when the worst possible
combination of events happen.
 Introduction
 The main requirement of a real-time system is not speed: living
organisms, unregarding their reaction speed, works in real-time
with respect to their environment;
 The main requirement of a real-time system is rather
predictability, i.e., it must be capable of guaranteeing
that temporal constraints (which are consequence of the
environment itseld) are met;
 The problem holds whatever the processor speed is: if we have
more processes concurrently executed, we must guarantee that
the temporal requirements of each process are met.

PREDICTABILITY is the KEY

 Introduction
 Real-time process: it must terminate within a given time
(deadline)
 A result produced after the deadline not only is “late”, but can
even “create a damage”,
 Depending on the consequences of a missed deadline, real-time
processes are also classified as:
 Hard: a catastrophic effect on the system (which means that all hard
deadline must be respected);
 Soft: it does not compromise the overall functioning of the system
(which means that all soft deadline must be respected as much as
possible).
 Introduction
 Hard real-time processes:
 Sensor acquisition;
 Detecting critical situations;
 Sensomotor planning;
 Controlling automated devices;
 Driving actuators.

«CATASTROPHIC» is a relative concept,

it does not mean that somebody needs to be injured.

A cleaning robot that cannot be controlled to avoid obstacles

IS a «CATASTROPHIC» event.
 Introduction
 Soft real-time processes:
 Streaming a video
 Collecting inputs from keyboard or other input devices;
 Representing the state of the system;
 Visualization of messages on a monitor.
 Introduction
 Many current real-time systems have been developed starting
from a classical timesharing kernel, e.g., QnX, VxWorks.
 In the last decades, many real-time extensions of Linux have
been proposed, e.g., RTLinux, RTAI, and also the mainline is
continuously updated to add new real-time features.
 Introduction
 RTOS can work for a standard x86 architecture or be
explicitly designed for embedded systems i.e., all the system
already mentioned plus eCos, FreeRTOS, etc.
 Writing Real-Time code for embedded systems typically
require to cross-compile on a computer «host» for a «target»
architecture.
 Introduction
 Traditional (non RT systems) usually provide:

 Primitives for asyncronous communication between processes

(e.g., named pipes, message queues: mutual exclusions
mechanisms, i.e., mutexes, can produce undesired phenomena,
such as deadlocks or priority inversion).
 Reentrant kernel of small dimensions and fast context switch (it
reduces the average response time, but does not guarantee that
temporal constraints are met).
 Introduction
 Desired characteristics: the availability of system calls
supporting:
 Schedulability analysis: the system must be able to evaluate a priori the
feasibility of the scheduling depending on the temporal properties of
processes;
 Optimal scheduling of periodic tasks: the system must be able to find the
scheduling that guarantees the highest processor occupation while
guaranteeing that temporal constraints are met (this requires the
availability of algorithms with dynamical priority assignment);
 Handling of sporadic and aperiodic tasks, with a proper schedulability
analysis;
Introduction
 Interprocess communication and synchronization primitives, with a
proper schedulability analysis;
 Worst Case Execution Time analysis: the system must be able to
evaluate the execution time of a process in the worst case; ideally,
WCET should be predicted by a static analysis of the code, not measured
during the execution;
 Recovery: critical tasks should be activated only if the system is able to
complete their execution within the deadlines specified by the user.
Otherwise, the system should notify that execution is not possible, and a
recovery strategy should be initiated.
 Introduction
 Internal mechanisms that influence the determinism in process
execution
 Interrupts;
 DMA;
 Cache;
 Memory management.

All these mechanisms improve performance «on average», but decrease predictability.
 Introduction
 DMA (Direct Memory Access) allows the system to transfer
data from the device to the memory. Since only one bus is
available, the DMA steals from the CPU a memory cycle (cycle
stealing). If both the DMA and the CPU make a contemporary
request, the DMA gets the highest priority.
 The response time of a task can not be predictable.
 Introduction
 The Cache works as a “mediator” or a “buffer” between the
CPU and the RAM with the purpose of speeding-up execution.
 In fact, it improves average performance, but the response time
of a process requiring some data become less predictable
because it depends on the fact that such data are available or not
in the cache.
 In case of a cache fault, the time becomes longer because it is
necessary to access RAM and to copy the data from RAM to
Cache.
 Solution 1: What about disabling cache?
 Introduction
 The interruptions generated by devices can delay control tasks
for an unpredictable amount of time.
 In traditional operating systems, every interrupts is associated to
a driver: the details of the underlying hardware are encapsulated
into the driver. While the interrupt handler are executed, other
interruptions are usually disabled.
 Solution 1: Disable interrupts, and get input data by polling devices
(polling is not very efficient);
 Solution 2: Disable all interrupts but one: a dedicated process reads data
from all devices, and share results with other processes;
 Solution 3: Minimize the work done by the driver: the only purpose of
the driver is to activate a process that reads data from devices.
 Introduction
 Memory paging techniques introduce unpredictability in case of
a page fault: the memory must be copied from the hard disk to
the RAM and vice versa.
 Solution 1: It is possible to disable paged memory and use a static
partitioning of physical memory.
 Scheduling
 A task is a sequence of instructions that, in absence of other
activities, is continuously executed by the processors up to
completion.
 A task that is potentially able to execute is said to be active;
 The active tasks that are waiting for the availability of the processor
are said to be ready (they are in the ready queue);
 A task that is currently using the processor is called in execution.
 A task can be blocked since it is waiting for resources (waiting in the
waiting queue)
Scheduling

scheduling
ready execution
preemption

signal wait on
resource resource
blocked
free busy
Scheduling
 The set of rules that determine the choice of the task
to be executed among the ready process is called
scheduling algorithm.
 A preemptive system allows a task in execution to be
interrupted (preempted) in every instant and moved to
the head of the ready queue, in order to allow for the
execution of a different task.
Scheduling
 Given a set of tasks J = {J1,…Jn) a scheduling is an
assignment of tasks to the processor versus time:
 In a preemptive scheduling it is possible that a task is executed in
disjoint temporal intervals:
 The instant in which the task in execution is preempted is called
context switch (it is necessary to save registers, stack, program
counter, etc.)
Non real-time Scheduling
 Batch systems: First Come First Served, Shortest Job First
 Time-sharing systems: used in a multi-user environment to
minimize the response time to user’s activity.
 Round Robin: the CPU time is divided into equal parts between all
ready tasks.
 Shortest Elapsed Time: the CPU privileges interactive tasks with a
small computation time (Linux scheduler adheres to this principle).
 Non real-time scheduling
 RR algorithm (intrinsically preemptive):
 1. RR chooses the task at the head of the ready queue, it enables a timer
that will expire after a time quantum Q, and assigns the CPU to the
selected task.
 2. If the tasks ends after the expiration of the timer, RR disables the
timer and executes a new ready task, as described in 1.
 3. If the task does not end within the defined time quantum, when the
timer expires the task is moved to the end of the ready queue, and the
CPU is assigned to the task at the end of the queue, as described in 1.

scheduling
ready execution
preemption
signal resource wait on
free blocked resource busy
 Non real-time scheduling
 SETF algorithm (preemptive)
 There are more queues that are internally handled using RR. Each queue
corresponds to a different time quantum.
 If there are ready tasks in more than one queue, the queues with a
smaller time quantum are privileged.
 The tasks in the i-th queue that do not end within the assigned time
quantum (presumably batch tasks) are moved to queue i+1, characterized
by a longer quantum and – therefore – lower priority.

Queue i The task uses

Duration of the whole
priority the time quantum
quantum Queue i+1
The task does
Queue i+2 not use the
whole quantum
Timing constraints
 Tasks have temporal constraints:
 Arrival time r: the time when the task becomes ready;
 Start time s: the time when the task starts its execution;
 Finish time f: the time when the task finishes its execution;
 Computation time C: the time required to execute the task (in absence
of interruptions);
 Deadline d: the maximum time within which the task must be
completed;
 Deadline criticalness: hard/soft.
Timing constraints
 is referred to as “phase” of the task;
D is the relative deadine (with respect to the arrival time).

Ci
Ji
ri si fi di

i
Di
 Timing constraints
 Tasks can be classified as periodic and aperiodic:
 Periodic tasks: an infinite sequence of identical activities, each called an
“instance” of the task;
 T is the period of the task: the arrival time rk+1 of the (k+1)-th instance
can be computed by adding T to the arrival time rk of the k-th instance.
 T, C and D are assumed to be identical for each instance.

r ik ri k+1
Ji
kTi Ci di (k+1) Ti

Di
Ti
Timing constraints
 Aperiodic tasks: an infinite sequence of identical activities, each called
an “instance” of the task;
 each instance is characterized by an arrival time r;
 T, C and D are assumed to be identical for each instance.

ri
Ji
Ci di

Di
 Active tasks

Start of the new Task ended (waiting for

request (next period) the next period)
active

scheduling
ready execution

preemption

signal wait on
resource free resource
blocked busy
Other constraints
 Tasks can have precedence constraints:
 Precedence relationships are expressed through a Directed Acyclic
Graph;
 We say that A must precede B (A<B) if it exists a path on the graph
from A to B;
 We say that A is an immediate predecessor of B if it exists an edge
directed from A to B.
Other constraints
 Example: recognition through stereo vision:
 Two tasks for sensor acquisition acq1 and acq2;
 Two tasks for image processing edge1 and edge2;
 One task for recognizing two-dimensional shapes 2d;
 One task disp for computing stereo disparity;
 One task H for determining the height of objects starting from the
disparity;
 One task rcn that integrates shape and height and verifies the
correspondence of objects with those that have been stored in a
database.
Other constraints
acq1 acq2

edge1 edge2

disp 2d

rcn
Other constraints
 Constraints on resources:
 We call resource: a data structure, a memory area, a portion of
code. If it can be used by more than one task is said to be a
shared resource.
 Mutually exclusive resources allow access to a single process at
a time.
 A mutually exclusive portion of code is also called a critical
section: the synchronization is handled through semaphores,
i.e., using the wait and signal primitives.
 Real-time scheduling
 Given a set of n tasks J = {J1,..,Jn} of which the DAG and
shared resources are known, the real-time scheduling problem
consists in finding a feasible scheduling such that:
 All task instances ends within their deadlines;
 All precedence constraints are met;
 All mutually exclusive resources are correctly accessed.

In its general formulation, the problem is a NP-hard problem.

There not exist an algorithm with polynomial complexity able to fine a feasible
scheduling
 Real-time scheduling
 A scheduling algorithm A* is said to be optimal if it has the
following property:
 If a set of tasks J is schedulable with A, that it is necessarily schedulable
also with A*;
 Vice versa, if J is not schedulable with A*, the set will not be
schedulable with any other algorithm.
 Real-time scheduling
 Some systems verifies that task constraints are
verified before its execution (in addition to the initial
schedulability test):
 Given a schedulable set J, to consider also the new task Jnew it is necessay
to verify the schedulability of J’=Jnew U J;
 In a system without this capability, the “time overflows” can be detected,
by possibly starting actions to handle them and reduce their effects;
 In a system with this capability, the “time overflow” are avoided.
 Real-time or anytime scheduling
 Anytime scheduling tries to find a compromise between
accuracy of results and timing constraints.
 Anytime tasks are composed of two parts: a critical subtask Mi
(hard) and an optional subtask Oi (soft). The overall
computation time is given by mi + oi.
 The system accept that Oi does not end within its deadline di:
the error is defined as i=oi – i, where i is the time assigned
by the CPU to the task.
 A scheduling is said to be feasible if all tasks that have been classified as
“hard” end within their deadlines;
 A scheduling is said to be precise if all tasks that have been classified as
“optional” end within their deadlines;
 The approach is suited for iterative algorithms which refine the
results in subsequent steps.
 Real-time scheduling
 Algorithms can be classified along the following axes:
 Preemptive – Non preemptive;

 Static – Dynamic;

 Off-line – On Line.
 Real-time scheduling
 Periodic tasks correspond to the major part of computation
activity:
 Signal acquisition;
 Filtering;
 Sensor data processing;
 Planning;
 Driving actuators;
 ...and many other.
 The activities above must be executed with a given periodicity
which is given by the application requirements.
 Real-time scheduling
 Example: controlling an automated vehicle equipped with
ultrasonic sensors for detecting obstacles:
 V: vehicle speed;
 Sb: breaking distance;
 T: ultrasonic sensor sampling period;
 D: maximum distance from obstacles detectable by sensors.
 To avoid any collision it must hold (in a simplified model)
VT+Sb<D, which poses a constraint on the period T.
 Periodic task scheduling
 Periodic task scheduling (we release some constraints)
 A1: the period is constant in time;
 A2: execution time is constant in time;
 A3: the relative deadline corresponds to the end of the period;
 A4: all tasks are independent (no precedence constraints or shared
resources).
 rik request time / arrival time of the k-th Instance of task i.

rik
Ji ri k+1= ri k+ Ti
kTi Ci (k+1) Ti= di

Ti=Di
 Periodic task scheduling
 For a set of periodic tasks T, we call utilization factor U the
ratio of time used by the CPU to schedule tasks.
 Ci/Ti is the ratio of time used by the CPU for the i-th task.
 U= Ci/Ti is the utilization factor, the ratio of time used to execute the
whole task set.
 U can be increased by making the computation time Ci longer, or by
making periods Ti shorter.
 The hyper-period is the least common multiple of all periods: scheduling is
identical for each hyper-period.

Hyper-period
 Periodic task scheduling
 For a given task set and a given scheduling algorithm, it
Uub an upper bound Uub it is not
may be possible to comput
possible to increase U more than the upper bound;
 In the previous case, Uub=  Ci/Ti=2/3+1/5=13/15;
 The processor is said to be fully utilized by the task set if an
increment (however small) of Ci makes the scheduling
unfeasible;
 For a given algorithm, Ulub (lower upper bound) is the
minimum among all the possible utilization factors computed
over all possible task set fully using the processor.
 The upper bound Ulub does not depend on the task set but only
on the chosen algorithm.
 Periodic task scheduling
 General schedulability theorem:
 A set of periodic tasks is schedulable with algorithm A if
it holds

U  i Ci / Ti  U lub ( A)

 Proof: it follows from the definition of Ulub;

 This is a sufficient condition for schedulability
(even if the condition is not satisfied, it can happen
that the task set is schedulable).
 Periodic task scheduling
 Non-schedulability theorem: for a set of periodic tasks
J={J1,..,Jn} , it does not exist any algorithm A such that
J is schedulable if
U  i Ci / Ti  1

 Proof (per absurdum): given T=T1T2T3…Tn

 if U > 1 it holds UT>T and then  Ti  Ci > T;
 Ti  is the number of times that Ji is executed in T, and
Ti  Ci is the computation time required by Ji in T;
 The computation time required by the set J in T cannot be
higher than T itself.
 U≤1 is a necessary condition for schedulability.
 Rate Monotonic
 Rate Monotonic algorithm
 It is a static algorithm (is based on fixed parameters, assigned to tasks
off-line);
 It is a priority-based algorithm (temporal constraints are transformed into
priorities);
 It can be easily implemented on a Unix-Posix scheduler, or any
other scheduler which is priority-based.
 Rate Monotonic
 A priority is assigned to each process: the priority Pi is inversely
proportional to the period Ti (i.e., tasks with a higher period get
a lower priority: if Ti<Tj then Pi>Pj);
 RM is optimal among static algorithms [Liu e Layland 73]: if a
task set is not schedulable with RM, it is not schedulable with
any other static algorithm.
 Rate Monotonic
 Definition:
 Critical instant: the instant in which all tasks become simultaneously
ready
 For example, in the case of two tasks with Pn < Pi:

Jn

Ji
Cn+2Ci
Jn

Ji
Cn+3Ci
 Rate Monotonic
 Proof of RM optimality (in a simplified case with two tasks).
 Let us consider a set of two tasks J1 and J2 with T1 < T2. If we
assign priorities with a different algorithm than RM, we get:
 P2 > P1;
 the scheduling is feasible if it holds C1+C2 ≤ T1 (Acond).

T1
C1
J1

C2
J2
 Rate Monotonic
 If, instead, we use RM we must consider two different cases.
Consider the critical instant in which both J1 and J2 are ready:

C1
J1
FT1 T2
J2
T2 - FT1
 Case 1) all requests of J1 are completed within the next request of J2,
that is, C1 ≤ T2-FT1, with F = floor(T2/T1);
 The scheduling with RM is feasible if (F+1)C1+C2 ≤T2 (RMcond)
 Rate Monotonic
 The proof of RM optimality works as follows: we analyize the
schedulability conditions for the algorithm A different from RM,
and we check if – under the same conditions – the task set is
schedulable also with RM.

J1
FT1 T2
J2

 By writing C1+C2 ≤ T1 (Acond) and multiplying for F we obtain FC1+FC2

≤ FT1, and since F≥1 we can write FC1+C2 ≤ FC1+FC2 ≤ FT1
 By adding C1 to each term we obtain (F+1)C1+C2 ≤FT1 + C1
 Since we have supposed C1 ≤ T2-FT1 (we are in Case 1) we get
(F+1)C1+C2 ≤FT1 + C1 ≤ FT1 + T2-FT1 ≤T2 (that is RMcond is satisfied).
 Rate Monotonic
C1
J1
FT1 T2
J2
T2 - FT1
 Case 2) The execution of the last request of J1 overlaps the next request of J2,
that is C1 ≥ T2-FT1 with F = floor(T2/T1);
 the scheduling with RM is feasible if FC1+C2 ≤FT1 (RMcond)
 Rate Monotonic
C1
J1
FT1 T2
J2

 By writing C1+C2 ≤ T1 (Acond) and multimplying for F we obtain

FC1+FC2 ≤ FT1, and since F≥1 we can write FC1+C2 ≤ FC1+FC2 ≤ FT1
(that is RMcond is satisfied).
 Since every task set which is schedulable with an algorithm A
different from RM is also schedulable with RM, RM is optimal
by definition.
 Rate Monotonic
 How can we compute Ulub for RM?
 In principle, we could consider all possible task sets (whose number is
unfortunately infinite), and compute Uub for every task set;
 Then we could choose Ulub as the minimum value among the Uub;

This approach is obviously unfeasible

 Rate Monotonic
 A situation in which Uub < 1 for RM
 With J1(T1=3,C1=1); J2(T2=4,C2=1); J3(T2=6,C3=2) we get U=11/12, and
the processor is fully utilized;

 In fact, we cannot increase the computational time of any task by

keeping the task set schedulable. Then Uub=11/12
 Computation of Ulub for RM
 We consider once again two tasks J1 and J2 with T1<T2 and P1>P2.
 F = floor(T2/T1) is the integer number of periods completed by J1 within T2:
considering the critical instant, there are F+1 requests of J1 within T2.
 Again, we must consider two cases:
 Case 1) All requests of J1 within T2 are completed before the next request
of J2, which means C1 ≤ T2-FT1

C1
J1
FT1 T2
J2
Computation of Ulub for RM
 The processor is fully utilized when C2 has its maximum allowed value,
which corresponds to the time not used by J1 within T2, that is when it
holds C1(F+1)+C2=T2 which implies C2=T2-C1(F+1)
 The corresponding utilization factor turns out to be:

 Remember that we want to find the minimum value for U (given that the
processor is fully utilized). The quantity between parentheses in the last
term is negative: and therefore the minimum value for U corresponds to
the maximum for C1, that is C1=T2-T1F.
C1
J1
FT1 T2
J2
Fully utilized!
 Computation of Ulub for RM
 Case 2) The execution of the last request of J1 within T2 overlaps with the
next request of J2, that is C1 ≥ T2-FT1

C1
J1
FT1 T2
J2
Computation of Ulub for RM
 The processor is fully utilized when C2 has its maximum allowed value,
which corresponds to the time not used by J1 within FT1, that is when it
holds FC1+C2=FT1 which implis C2=(T1-C1)F
 The corresponding utilization factor turns out to be:

 Again, we want to find the minimum value for U given that the processor
is fully utilized. The quantity between parentheses in the last term is
positive, and therefore the minimum value for U corresponds to the
minimum for C1, that is when C1=T2-T1F.

J1
FT1 T2
J2
Computation of Ulub for RM
 In case 2), by substituting C1=T2-T1F in the expression of U, we obtain
(the same result could be obtained in case 1)

 By defining

Since 0≤G<1, the numerator [G(1-G)] is positive and U increases with F.

The minimum value for U corresponds to the minimum of F, i.e., F=1
Computation of Ulub for RM
 We now compute the derivative of U with respect to G

 The derivative is null when

 The negative solution is discarded: by substituting G2 in U we finally

find the minimum value:
 Computation of Ulub for RM
 Ulub =1 when T2/T1=floor(T2/T1). This means that
the period of the lower priority task must be a multiple of the
period of the other task (G=0 in the previous slide).
 Analogously, it is possible to demonstrate that, for a generic
task set composed of n tasks, it holds Ulub= n(21/n-1)
 When n tends to infinite, Ulub=ln 2 = 0.69
 Ulub=1 if there are harmonic relationships among task periods.

A very important result: in real applications it often happens that there are
harmonic relationships among tasks
 Computation of Ulub for RM
 Schedulability theorems:
 U < Ulub
 For RM with n tasks it holds,

U lub  n 21/ n 1
n  1,U lu b  1
n  2,U lu b  0.83
n  3,U lu b  0.78
n  ,U lu b  0.69

 In the case of harmonic relationships between periods, Ulub = 1.

 We say that the periods of the task set have harmonic relationships if, by
taking every possible couple of periods Ti and Tj, it either holds Ti=mTj
or Tj=mTi, with m integer.
 Earliest Deadline First
 Earliest Deadline First algorithm
 It is a dynamic algorithm (i.e., it is not based on the assignment of off-
line parameters, e.g., priorities);
 It assigns the CPU to the task with the closest deadline;
 It cannot be easily implemented on a Unix-Posix scheduler (however,
there are systems implementing it);
 It is possible to imagine that every tasks is assigned a priority that is
inversely proportional to the difference between the deadline and the
current time;
 It is an optimal algorithm: if a task set is not schedulable with EDF, it
does not exist any other algorithm A that can schedule them.
 EDF can also be used for a set of non periodic tasks, each
characterized by an arrival time and a deadline.
 Earliest Deadline First

 Schedulability theorem
 A task set is schedulable with EDF if and only if
U  i Ci / Ti  1

 For EDF, Ulub= 1 (optimality)

 The necessary conditions has been already proven;
 We do not give a proof of the sufficient condition.
 Rate Monotonic
 Let us analyze a situation in which it is possible to schedule a
task set with EDF but not with RM.
 With J1(T1=3,C1=1); J2(T2=4,C2=1); J3(T2=6,C3=2) we get U=11/12. If
we set C3=2.5 the task set cannot be scheduled with RM;

 However, it can be scheduled with EDF

 Earliest Deadline First
 Note: in the previous example, when two tasks have the same
deadline, in this case we used FCFS.
 FCFS (First Come First Served): the task that is at the head of
the ready queue is chosen the first.
 A different policy could be adopted as well (e.g., the two tasks
could be scheduled concurrently in Round Robin): the policy
adopted to choose among two tasks with the same deadline or
priority does not influences the schedulability with EDF or RM.
 A new condition for RM
 In 2011, [Bini, Buttazzo and Buttazzo] proposes a
new schedulability condition for RM, which proves
to be more efficient.

Bini, E., Buttazzo, G., Buttazzo, G., A Hyperbolic Bound for

the Rate Monotonic Algorithm, Proc. of the 13th Euromicro
Conference on Real-Time Systems (ECRTS 2001), Delft, The
Netherlands June 13-15, 2001.
 A new condition for RM
 Why «hyperbolic bound»? Let’s graphically visualize its
behaviour with 2 tasks.
 Deadline Monotonic
 Deadline Monotonic algorithm [Leung Whitehead 1982]
 It is a static algorithm (as like as RM);
 It does not require that the relative deadline D corresponds to the end of
the period.

r ik ri k+1
Ji
kTi Ci di (k+1) Ti

Di
Ti
 Deadline Monotonic
 We have released the constraint A3:
 A1: the period is constant in time;
 A2: execution time is constant in time;
 A3: the relative deadline is constant for every period;
 A4: all tasks are independent (no precedence constraints or shared
resources).
 Deadline Monotonic
 Every process is assigned a priority that is inversely
proportional to the relative deadline.
 The schedulability test could be the same as RM by substituting
T with D.
 C / D  n2
i i i
1/ n
1

 However, this is to much pessimistic.

 We can use a more complex but more efficient test, which is
based on the concept of critical instant: for every process Ji, the
sum of the execution time Ci and delays due to higher priority
tasks, must be less or equal to Di.
 Deadline Monotonic
 Schedulability test for Deadline Monotonic
 Ii(k) interference on task Ji due to a higher priority task Jk;
 Fi(k) number of periods of Jk interely contained within the relative
deadline of Ji;
 Ii interference on Ji due to all higher priority tasks.
 The interference on Ji due to Jk can be computed as:
 Ii(K) = [Fi(k) + 1]Ck , with Fi(k)=floor[Di/Tk]

Jk
Fi(k)Tk Di
Ji Ti
 Deadline Monotonic
 The interference on Ji due to all higher priority tasks can be
computed as:

 The schedulability test can be written as:

 Deadline Monotonic
k
Jk
Fi(k)Tk
Di Ti
Ji
 It is an only sufficient (and too pessimistic) condition. If the
deadline of Ji is within the execution of Jk the interference is:
Ii (k )  Fi (k )Ck  k , k  Di  Fi (k )Tk
 A more accurate estimate is the following
I i (k )  Fi (k )C k  min Ck , Di  Fi (k )Tk , Ii   j1

Fi (k )Ck  min Ck , Di  Fi (k )Tk 
i 1

 This is a sufficient condition too. It is possible that a higher

priority task does not interfere.
 Deadline Monotonic
j
Jj

Jk k

Di Ti
Ji
 The real interferences on Ji are Ii(j)=4Cj and Ii(k)=2(Ck);
 According to the previous test it holds Ii(j)=Fi(j)Cj + Cj = 4Cj
and Ii(k)=Fi(k)Ck+Ck=3Ck.
 Audsley Theorem
 In order to define a necessary and sufficient condition it is
required to compute the exact interference. This is in principle
very complex, since it requires to simulate the whole scheduling
of the task set for a hyperperiod.
 In 1990 Audsley proposes an algorithm:
 tk instant when Ji could end its execution, in absence of interferences due
to higher priority tasks;
 Iik interference on Ji due to higher priority tasks in the interval [0, tk]
 Audsley Theorem
Ci Ti Di
 Example
J1 1 4 3
J2 1 5 4
J3 2 6 5
J4 1 11 10
 Consider J4. We initially assume that there is only one instance of every
higher priority task. The first instant t0 in which J4 could end is given by:
i
t0   C j  5
j1

 But the real interference in [0 t0) can be computed as I40=5 and therefore,
since it holds I40+C4>t0, J4 cannot really end in t0;
 The next time instant in which J4 can end is t1= I40+C4=6, but also in this
case the interference in [0 t1) turns out to be I41 =6 and I41+C4>t1, which
does not allow J4 to end in t1;
 J4 can end when I4 n+C4 =tn.
 Audsley Theorem
 Audsley theorem
 A task set J={J1,..,Jn} is schedulable with Deadline Monotonic if and
only if

𝐼𝑖−1

 The same theorem provides necessary and sufficient conditions for RM.
 Audsley Theorem
 Audsley algorithm to guarantee the schedulability of a periodic
task set.
Guarantee(J)
 Non-periodic tasks
 In a realistic case we must schedule mixed sets composed of
periodic and aperiodic tasks. We assume to use RM for periodic
tasks.
 It usually assumed that periodic tasks are hard real-time tasks,
whereas aperiodic tasks can either be hard, soft, or non real-
time.
 Concerning hard real-time tasks we want to guarantee schedulability;
 Concerning soft and non real-time tasks we want to minimize the
response time.
 Non-periodic tasks
 Aperiodic (hard real-time) tasks:
 If we want to guarantee a priori the schedulability of every possible
instance, the only solution is to define a minimum interarrival time (mit),
i.e., a minimum time that must pass between the arrival time of two
subsequent instances. In this case the task is referred to as sporadic
instead of aperiodic;
 Sporadic tasks are then considered as if they were periodic tasks, by
using the mit as the period of the task.
 If we want to guarantee the schedulability of a single instance, we must
adopt an online test and – if necessary – to reject the task if it is not
schedulable.
 Non-periodic tasks
 Background scheduling
 Non-periodic tasks
 The aperiodic tasks can be scheduled in background (high response time:
possible risk of starvation).
 Background scheduling can be adopted either when we use RM or EDF for
periodic tasks:
 Aperiodic tasks are scheduled either with (non real-time) FCFS or with
EDF (remember that EDF is optimal also for non-periodic tasks);
 Aperiodic tasks do not interfere with higher priority tasks, therefore the
schedulability tests for periodic tasks are not affected by aperiodic tasks;
 The system works with two queues, one for real-time periodic tasks, the
other of non-periodic tasks.
High priority

CPU
Low priority (background)
 Non-periodic tasks
 An online test to verify if a task can be scheduled (sufficient
condition)
 To compute the available CPU time it is possible to compute the hyper-
period H of periodic tasks (least common square of periods) and  = (1-
U)H (the idle time for each hyper-period
 An aperiodic instance with computation time Ci and deadline di can be
guaranteed if
𝐶𝑖
𝑡 + 𝑐𝑒𝑖𝑙 𝐻 ≤ 𝑑𝑖
Φ

 Or, in the worst case (e.g., for any arrival time t)

ceil (C / )H  D
 It is possible to make analogous considerations for task sets.
 If Ci=4 and =0.3 a maximum of 4 hyperperiods are required

t
=0.3
di

H H H H H

𝐶𝑖
𝑡 + 𝑐𝑒𝑖𝑙 𝐻 ≤ 𝑑𝑖
Φ
 Non-periodic tasks
 Sufficient condition for a set of task ordered with increasing deadline (j<i
if and only if dj<di) scheduled in background with EDF

 Si 
i  1,..., n it must hold t  ceil   H  di

Si   j 1 c j (t )
i
where   (1  U )H

 cj(t) residual computational time of task Jj at time t;

 Notice that this is a task to be made online, at time t when a new
task Ji requests to be scheduled.
 Non-periodic tasks
 A sufficient and necessary condition requires to explicitlty
compute idle times, i.e., intervals when the CPU is not busy
with periodic tasks.
 Idle times can be computed off-line and stored in a vector
 We define (t)=1 if the CPU is idle in t, (t)= 0 otherwise
 The integral (t1,t2) defines the amount if time in which the CPU is idle
in the interval [t1,t2]
 The following properties hold:
 (t+kH)= (t)
 (0,kH)=k
 (t) can be stored in a vector with a maximum dimension of H
entries.
Non-periodic tasks
 Non-periodic tasks
 The schedulability of a single task Ji is guaranteed if and only if
Ci  (ri , di )

 …whereas, for a set of n aperiodic tasks


i
i 1,..., n it must hold j 1
c j (t)  (t, d i )

 Also (0, t) can be stored in a vector of H entries, by computing:

(a, b)  (0, bh )  (0, ah )  [ floor (b / H )  floor (a / H)]

where ah and bh are the remainders of the divisions a/H and b/H,
respectively.
 Non-periodic tasks

ah
bh a b

H H H

(a, b)  (0, bh )  (0, ah )  [ floor (b / H )  floor (a / H)]

where ah and bh are the remainders of the divisions a/H and b/H,
respectively.
 Non-periodic tasks
 It is possible to schedule aperiodic process with a server, that is,
a periodic tasks that is devoted to serve the requests of aperiodic
tasks.
 Different periodic servers:
 Polling Server;
 Deferrable server;
 Priority Exchange;
 Sporadic Server.
 Non-periodic tasks
 The Polling Server is characterized by a period Ts and a computation time
Cs, also referred to as Server Capacity.
 The Server is activated at regular intervals with the purpose of
executing aperiodic tasks;
 In absence of pending requests, the residual capacity is lost until the
beginning of the next period. An aperiodic task that makes a request
while the Server is active will be executed in the next period.
 Usually the Polling Server is scheduled as a periodic task with RM and
maximum priority (lowest period).
 Non-periodic tasks
 Polling server example
Non-periodic tasks
 The schedulability test requires, first of all, to guarantee all periodic
tasks Ji, including the Polling Server


n
i 1
Ci / Ti  Cs / Ts  U lub
 If there are m sporadic tasks Jj that require to be guaranteed for all
possible instances, we must consider the worst case and assume that
their periods equal to the minimum interarrival time

i 1 Ci / Ti   j 1 C j / Tj  Cs / Ts  Ulub
n m
Non-periodic tasks
 Next we can guarantee a single instance of an aperiodic task Ja with
computational time Ca executed within the Polling Server.
 Sufficient condition:
 Let Fa=floor (Ca/Cs) the number of complete Server periods that
are necessary to schedule Ja;
 In the worst case (i.e., if Ja makes request immediately after the
beginning of the Server period) the execution of Ja starts after Ts
(i.e., at the following period) and terminates after (Fa+1)Ts;
 Therefore it must hold, in the worst case

ra Ts  (Fa 1)Ts  d a

 Or
(Fa  2)Ts  Da
 Non-periodic tasks
 In order to have necessary and sufficient conditions, it is
necessary to exactly compute the completion time of the
aperiodic task in the last Server period.
 To this purpose, we must assume that the Server has the maximum
priority, and therefore the minimum period Ts ≤ mini(Ti)).
 Non-periodic tasks
 Fa=floor(Ca/Cs)
 Ga=floor(ra/Ts) è is the integer number of Server periods up to ra,
 The start time of Ja is (Ga+1)Ts (in the worst case)
 CsFa is the Server capacity used by Ja in Fa Server periods
 The residual computation time in the last period is Ra=(Ca-FaCs)
 The actual completion time of Ja is fa=(Ga+1)Ts + FaTs+Ra
 The task can be guaranteed if and only if (necessary and
sufficient conditions)
(Fa  Ga 1)Ts  Ra  d a
Non-periodic tasks
 As already discussed, the maximum delay in the execution of the
aperiodic task happens when Ja makes request an instant after the
beginning of the Server period.
 Without loosing generality we can imagine that the Server starts
at t=0 and that ra=0+;
 In this case the aperiodic task is schedulable if its maximum
delay is lower than its relative deadline Da=da-ra, that is if and
only if
(Fa 1)Ts  Ra  Da

 Notice the difference with the case that the Polling Server HAS
NOT the maximum priority
(Fa  2)Ts  Da
 Non-periodic tasks
 The schedulability test can be extended to a set of aperiodic tasks
ordered with increasing deadline and scheduled with EDF
 Suppose that, at time t, a new aperiodic task Jh with deadline dh
makes a request;
 the overall computation time Sh required in the interval [t, dh] is
given by the sum of the residual computation times ci(t) of all
aperiodic tasks Ji with deadline di ≤ dh (including Jh itself)
 It is necessary to consider the case that the request of Jh arrives
while another aperiodic task is being executed by the Server. In
this case, a part h=cs(t) of Sh can be immediately executed (i.e.,
without waiting for the next period of the server).
 Non-periodic tasks
 A set of aperiodic tasks is guaranteed at time t if and only if
 Non-periodic tasks
 The Deferrable Server has a period Ts and a computation time Cs, referred to
as Server Capacity.
 At regular intervals, the Server is activated to execute aperiodic tasks.
 In absence of pending requets, the residual capacity is preserved (and
then restored to its maximum value at the beginning of the next period).
An aperiodic task which arrives while the server is active will be served
immediately (if the server is not busy with other requests and/or there is
residual capacity left).
 It is scheduled as a periodic task with RM (usually with maximum
priority, i.e., minimum period)
Non-periodic tasks
 The Deferrable Server violates hypotheses A1,…,A4 of periodic tasks, in
particular, it is no more true that a ready task is immediately executed as
long as there are no tasks with higher priority (since the Deferrable
Server can decide to execute later in its period, if there are no pending
requests at the beginning of the period).
 This has an impact on the Ulub computation, that must be updated as
follows:
 Real-time communication
 Mechanisms for task communication
 Access to shared resources (semaphores and mutex)

 Pipes e named pipes

 Sockets

 Message queues

 In the case of real-time communication we want to

 guarantee the execution times of tasks;

 guarantee that communication works in real-time, e.g., data

are guaranteed to be sent/received within a given deadline.
 Real-time communication
 Access to shared resources
 Cons for Real-time 
 A task can be blocked by another task with lower priority: it is necessary
to modify the schedulability tests to take into account this possibility;
 It is possible the priority inversion phenomena happen;
 It is possible that deadlocks happen.
 Pros for Real-Time 
 If mutex are used to communicate through a shared memory, the
memory will always contain the last data written by the producer, i.e.,
which contains up-to-date information.
 Consider a task that computes the position of a robot and another
task that uses such position to compute a trajectory: if the
localization task has a higher frequency, it produces more data that
required. However, with a shared memory mechanism, position data
are overwritten as soon as new data are available (the information is
always up-to-date).
 Real-time communication
 Pipes and Named pipes (FIFO queues)
 Differently from pipes, the named pipes exist in the file system as a
special device file (in the directory /dev);
 Pipes allow data exchange between tasks with a common ancestor (since
this is required for passing the pipe descriptor). Named pipes, on the
opposite, require only to know the name of the special file.
 Differently from pipes, when I/O are terminated, the FIFO queue
remains in the file system for a subsequent usage.
 Cons for Real-time 
 The time requested to read all messages in the queue can vary if the
producer and the consumer do not have the same period.
 Pros for Real-Time 
 Writing and reading can be non-blocking procedures (i.e., they do not
put additional constraint on the schedulability of tasks).
 Real-time communication
 Socket
 Sockets are a more general communication approach, suited also for
tasks distributed in a network.
 A task can send or receive messages on a socket.

 Sockets (if they are “stream sockets”) are handled as a FIFO queue. For
“datagram sockets” there is no guarantee on the order of arrival of
packets.
 Cons for Real-time 
 The time requested to read all messages in the queue can vary if the
producer and the consumer do not have the same period.
 Pros for Real-Time 
 Writing and reading can be non-blocking procedures (i.e., they do not
put additional constraint on the schedulability of tasks).
 Real-time communication
 Message queues
 They can be described as a linked list in the kernel address space.
 A task can send messages to the queue or receive messages from the
queue.
 The mechanism can be of a publish/subscribe type:
 Tasks can subscribe to messages of a given type;
 Task can publish messages of a given type;
 All tasks are guaranteed to receive all the messages of a subscribed type.
 A queue is normally handled using a FIFO policy; however, it is possible
to use different policies (getting older messages, or only messages of a
given type).
 Cons for Real-time 
 The time requested to read all messages in the queue can vary if the
producer and the consumer do not have the same period.
 Pros for Real-Time 
 Writing and reading can be non-blocking procedures (i.e., they do not put
additional constraint on the schedulability of tasks).
 Access to shared resources
 It is necessary to modify the schedulability test;
 Binary semaphores for mutual exclusion.
 Problem: priority inversion
 A high priority task is blocked by a low priority task for an indefinite
time;
 If the low priority task enters into the mutual exclusion region the first,
the high priority task is blocked;
 The blocking time can become longer because of medium priority tasks
that preempt the low priority task (even if the medium priority tasks do
not access the mutual exclusion region).
 In addition, there are well-known problems, such as deadlocks.
Access to shared resources
The blocking time of J1 is unpredictable!
P(S1)
J1
P(S1)
J2

J3
P(S1) V(S1)
 Access to shared resources
 It can be solved by forbidding preemption inside critical region.
But it is reasonable only in the case of “short” critical regions.
 A more sound and efficient solution is to regulate the access to
shared resources through dedicated access protocols..
Access to shared resources
 Priority Inheritance protocols
 A task is referred to as blocked when it is waiting for the execution
of a lower priority task;
 Tasks do not spontaneously suspend themselves before they finish;
 Every task has a nominal fixed priority, assigned at the activation
time (i.e., we are using RM or DM)
 Tasks with the same priority are served using a FCFS (First Come
First Served) policy;
 Task J1, .., Jn are ordered with decreasing nominal priorities;
 Critical sections can be nested;
 We assume binary semaphores.
 Access to shared resources
 When a task J1 is blocked at the entrance of a critical region, it
passes its priority to the task J2 that has blocked it. J2 inherits
the highest priority among all tasks that it is blocking.
 When leaving the critical region, J2 is restored to its nominal
priority value.
 Priority inheritance is transitive: if J3 blocks J2, which blocks J1,
J3 gets the priority of J1.
 There are two blocking types: direct and indirect blocking.
Access to shared resources
Direct blocking Prio(J3)=Prio(J1)
P(S1) V(S1)

J1

J2

J3
P(S1) V(S1)

Critical section Z1 Indirect blocking

 Access to shared resources
 Protocol properties
 pi e Ti correspond to the priority and period of Ji
 P(Si) e V(Si) are the undivisible operations wait and signal on the mutex Si
 zi,j is the jth critical section of Ji
 di,j is the duration of zi,j in absence of interruptions from other tasks.
 i is the set of critical sections of Ji
 i,j is the set of critical sections of Jj that can block the higher priority task
Ji (i.e., pj < pi ).
 i,j* is the set of external critical section of Jj (i.e., not nested within
another section) that can block the higher priority task Ji
 i* is the set of all critical sections that can block Ji (i.e., by considering
all lower priority tasks).
 Access to shared resources
 Properties of Priority Inheritance (1)
 Given J0 and n lower priority tasks Ji, each task Ji can block J0 at maximum
for the duration of a critical section.
 In fact, in general, a higher priority process JH can be blocked by JL only
if JL is already inside one of the critical sections in the set H,L*
 After JL has exited from the critical section, it is preempted by JH and it
cannot block it anymore.
 If there are n tasks Ji with lower priority than J0, each of them can block
J0 for – at maximum – the duration of a critical section in 0,i*

P(S1) P(S2) V(S2) V(S1)

J1

J2
P(S1) P(S2) V(S2) V(S1)
 Access to shared resources
 Properties of Priority Inheritance (2)
 If there are m semaphores that can block J0, than J0 can be blocked – at
maximum – m times.
 Since semaphores are binary (mutexes), only one lower task priority task
Ji can be inside a critical sections that block J0.
 Once Ji exits from the critical seJction, it cannot block J0 anymore.
i
 If there are m busy semaphores, each of them can block J0 only once.
 Access to shared resources
 Putting (1) and (2) together, we obtain that a task Ji can be blocked (at
maximum) for the duration of bi=min(n,m) critical sections.
 To make an estimate of the blocking time Bi in the worst case, we can
choose the bi sections with longest duration.
 This values will be used for the schedulability analysis.
 Access to shared resources
 Example
 J1(T1=4,C1=1, z1,1 with d1,1=0.1, z1,2 with d1,2=0.2, z1,3 with d1,3=0.1);
 J2(T2=6,C2=2, z2,1 with d2,1=0.2);
 J3(T3=8,C3=2, z3,1 with d3,1=0.1, z3,2 with d3,2=0.1).
 S1 regulates access to z1,1 and z2,1
 S2 regulates access to z1,2 and z3,1
 S3 regulates access to z1,3 and z3,2

 There are no nested regions

 1,2={z2,1} (direct blocking)
 2,3={z3,1, z3,2} (indirect blocking)
 1,3={z3,1, z3,2} (direct blocking)
 Access to shared resources
 Example (2)
 Let us consider J1
 there are at maximum n=2 lower priority tasks that can block it;

 there are at maximum m=3 semaphores that can block it;

 the task can be blocked at maximum for 2 critical sections,

B1=0.2+0.1;
 Let us consider J2
 there are at maximum n=1 lower priority tasks that can block it;


there are at maximum m=2 semaphores that can block it;
 the task can be blocked at maximum for 1 critical sections, B =0.1;
2
 Let us consider J2
 It can never be blocked! A task can be blocked only by lower priority
tasks, otherwise we say that it is preempted.

 It can happen that m<n when there are a number of low priority tasks
which use the same semaphore!
 Access to shared resources
 Problems:
 It does not prevent from deadlock.

 This problem can be solved by imposing that tasks, if they want to

acquire more than one semaphore, must follow a predefined order.

Code of J1 Code of J2

P(S1) P(S2)
P(S2) P(S1)
V(S2) V(S1)

V(S1) V(S2)
 Access to shared resources
 Problems:
 It can cause “blocking in cascade” (J1 is blocked for n
critical sections)

P(S1) P(S2) V(S2) V(S1)

J1
P(S2) V(S2 )
J2

J3
P(S1) V(S1)
Z1 Z2
Access to shared resources
 Priority Ceiling (solves the problem of deadlocks and blocking in
cascade)
 Offline, every semaphore S is assigned a priority ceiling c(S),
corresponding to the highest priority among all tasks that can use
that semaphore.
 At time t, let J1 be the task with highest priority among the ready
tasks.
 Let S* be the semaphore with the highest priority ceiling among all
semaphore that have been taken by other tasks Ji different from J1,
and let c(S*) be its ceiling.
 In order to enter a critical section protected by S, J must have a
1
priority higher than c(S*), otherwise J1 is blocked on S* by the
task that holds S*.
 If a task J blocks higher priority tasks, it inherits the highest
i
priorities among the blocked tasks (as in the case of priority
inheritance).
 Inheritance is transitive.
Access to shared resources
 Example
 The task J0 accesses in sequence to the critical sections Z0 and Z1,
protected by S0 and S1.
 J1 accesses to Z2, protected by S2
 J2 accesses to Z2 and make a nested access to Z1.
 C(S0) = C(S1) = priority of J0
 C(s2) = priority of J1
 Access to shared resources
C(S0) = C(S1) = priorità di J0 P(S0)
C(S2) = priorità di J1 Prio(J2)=
Prio(J0) V(S0) P(S1) V(S1)
J0
P(S2)
Prio(J2)=
Prio(J1) V(S2)
J1

J2 P(S2) P(S1) V(S1) V(S2)

Z2 Z0 Z1
Access to shared resources
 Timeline:
 t0: J2 executes and enters z2, by taking S2
 t1: J1 becomes ready and executes by interrupting J2
 t2, J1 tries to enter z2, but is blocked on S2. J2 takes the CPU back
by inheriting the priority of J1 (direct blocking).
 t3: J2 enters z1. It can do that, because, no other semaphore is taken
by other tasks.
 t4: J0 becomes ready, and it starts executing by interrupting J2.
 t5: J0 tries to enter z0. However, it is blocked, since its priority p0 is
not greater than c(S1) = p0. J2 continues to execute with priority p0
(ceiling blocking).
Access to shared resources
 t6: J2 exits from z1, it releases S1 and it goes back to the older
priority p1. At this time, J0 wakes up and it interrupts J2 because
p0> c(S2)=p1. J0 executes by entering the critical sections z0 and z1
in sequence.
 t7: J0 ends and J2 restarts executing in the critical section Z2 with
priority p1.
 t8: J2 exits from z2 and goes back to its nominal priority p2. J1
wakes up and interrupts J2 by accessing z2.
 t9: J1 ends. J2 completes its execution.
 Access to shared resources

 Properties of Priority Ceiling

 Theorem 1: Priority Ceiling prevents from deadlocks.

 Theorem 2: a task is blocked – at most – for the duration of a critical

section in the set i* (it prevents from blocking in cascade)
 To make an estimate of the blocking time Bi in the worst case, we can
choose section with the longest duration.
Access to shared resources

 Schedulability analysis with access to shared resources

 All tasks are periodic, with a constant period.
 The maximum execution time is constant.
 Priority is assigned with RM.
 Access to shared resources
 Assumption: the sufficient conditions for n tasks scheduled with RM can
also be written as follows, since the conditions must be valid for every subset
of the n tasks.

 If we want to consider shared resources with Priority Ceiling (sufficient

conditions):

 Bi is the maximum blocking time of Ji, that is the longest critical section
belonging to the set *i
 If we want to consider shared resources with Priority Inheritance, we must
apply the same formulas, by properly updating the value of Bi as described
in the previous slides.
 Real-Time communication
 Problem: real-time communication for a set of processors
connected on a communication bus:
 A set of tasks Ji is executed on CPUi (also referred to as a “nodei”);
 Each task Jik produces messages mik either periodically or aperiodically;

 How can we guarantee that messages are delivered periodically or

aperiodically within a given deadline?
 In the following we take the CAN bus as an example, but the principles are
general.

Node1 Node2 Node3

Node4 Node5
 Real-Time communication
 The CAN (Controller Area Network) is a broadcast digital bus
designed to operate at speeds from 20kb/s to 1Mb/s:
 It has become a standard de facto for automotive control;
 The CAN protocol works using a collision detection and resolution
scheme
 the message to be transmitted among all competing messages at the n

nodes is chosen according to its identifiers: the lowest identifier

message is transmitted.
 Thanks to the collision detection and resolution scheme it is possible to
implement real-time algorithms such as RM, EDF, or DM for message
scheduling.
 Real-Time communication
 The bus is a wired AND (or wired OR) channel connecting
all nodes;
 The media access protocol works by alternating contention
and transmission phases;
 Let L be the length of the bus and Vp the propagation speed
of the signal:
 the time axis is divided in bit slots which must be larger than or
equal to Tp=2L/Vp, the time the signal takes to travel back and forth
along the channel;
 This limits the maximum available bit rate to the theoric bound
Brmax=1/ Tp.
 Real-Time communication
 The CAN protocol has the following packet format, where the
size of the fields is expressed in bits:
 The identifier field is used for
 Describing the meaning of the data;
 Encoding priorities.
 The standard requires that all contending packets have a unique
identifier
 This means that not all of the 11 bits in the identifier field can be used
for the priority (the identifier must be used to encode, for example, the
the sending node, etc.)
1 11 6 0-64 16 2 7 3
start identifier control data checksum ACK ED IS
 Real-Time communication
 The other fields are:
 Control field containing information on the type of message
 Data field containing the actual data to be transmitted
 Checksum used to check the correctness of the message bits
 ACK used to acknowledge the reception
 ED used as an ending delimiter to signal the end of the message
 IS used as idle space to separate une frame from the following

1 11 6 0-64 16 2 7 3
start identifier control data checksum ACK ED IS
 Real-Time communication
 In the following we distinguish between
 Bit slot: a slot for transmitting a bit on the bus, whose temporal length
depends on the length of the bus and the speed of the signal as discussed
before;
 Packet slot: a slot for transmitting a whole packet

 In the following we assume that a packet slot includes a fixed

number of bit slots;

 Also notice that a message is possibly composed of a number of packets: this
can require to execute the contention phase more times in order to transmit a
whole message.
 Real-Time communication
 If a node wishing to transmit finds the channel idle (i.e., this is the purpose of
the idle space)
 It waits for the next packet slot;

 It starts an arbitration phase by issuing a start of frame bits.

 All nodes having a message to send can content for the channel transmitting
the identifier bits (which include the priority) during the arbitration slots,
one bit for each slot starting from the most significant.
 Real-Time communication
 Suppose, for example, that collisions among the identifier bits are solved
with a logical AND.
 If different messages are written on the bus at the same time, the result
on the bus is the lowest bit written.
 Remember that we are assuming that highest priorities correspond to
lower identifiers.
Node 1 0 1

Node 2 0 0

Node 3 0 0

BUS 0 0
 Real-Time communication
 If a node reads its priority bits on the channel without any change,this means
that it is the winner of the contention and gets the rights to transmit.
 If one of its bits appears changed when read from the bus, this means there is
a higher priority contending message and it withdraws.

Node 1 withdraws

Node 1 0 1

Node 2 0 0 1 0 0 1 1 0

Node 3 0 0 1 1
Node 3 withdraws

BUS 0 0 1 0 0 1 1 0
 Real-Time communication
 Bus scheduling problems arise when periodic tasks with hard
deadlines must communicate over a bus: this creates a periodic
communication with a hard deadline.
 The problem has a strong similarity to the processor scheduling
problem
 The resource to be scheduled is the BUS;
 The tasks are the messages which must be sent, each having a hard
deadline.
 Has we have discussed, the natural protocol for this situation is
a slotted contention protocol: each node desiring to transmit will
contend at a certaing priority level.
 The problem is to assign the priorities in such a way that all the
individual message deadlines are met.
 Real-Time communication
 Specifically, nodes produce
 periodic messages m={m1... mn}
 with mj=(Cj,Tj),
 Where Cj is the “transmission time” and Tj is the period
(corresponding to the Relative Deadline in RM)
 “transmission time” corresponds to the “computational time” in processor
scheduling
 “transmission time” corresponds t a given number of packets, each being
composed of a fixed number of bits
 Real-Time communication
 There are three important issues that distinguish the bus
scheduling problem from the processor scheduling problem:
 Task preemption;

 Priority level granularity;

 Buffering.

 We will investigate how these issues affect standard real-time

scheduling algorithms, in particular RM.
 Real-Time communication
 Task preemption
 In processor scheduling, it may be reasonable that a task can be preemted
at any time and resumed later at the point of preemption;
 This is not appropriate for bus scheduling: any bus transmission that is
preempted must be entirely retransmitted (because of the initial
arbitration phase required to avoid collisions);
 In the following we assume that message lenghts and deadlines are an
integer number of packet lengths and packet transmission times are
synchronized to packet boundaries.
 Real-Time communication
 The granularity of priority levels
 In the processor scheduling case, it is reasonable to assume that there is
a sufficient number of priority levels to assign distinct priorities to each
task;
 In the bus scheduling case, this is no longer true;
 To transmit a priority bit and resolve the contention, it takes at least a
round trip propagation delay of the bus Tp: than «bits» are valuable
resources, and priorities necessarily have a limited number of bits,
which yields a limited number of distinct priority levels;
 This could result in two packets contending at the same level even
though one should have higher priority than the others: this can produce
priority inversion phenomena.
 Real-Time communication
 Buffering problems
 Hard deadlines for message packet transfer can arise from task deadlines, but
also from buffer limitations.
 If only one buffer is available, then the message packet in the buffer must be

sent before the second packet arrives;

 When additional buffer are available, the deadline of the transmission of a

message packet can be extended.

 Real-Time communication
 Problem formulation
 We consider only periodic messages transmitted over a common bus;
 The transmission of packets are divided int packet slots: packets are
initiated at the slot boundaries, by contending for the slot on the basis of
their priorites;
 Ties, if any, are broken arbitrarily;
 Once a packet starts transmission, it cannot be preempted.
Real-Time communication
 If a message is ready for the first time at time r(0) with period T, then
it will be ready for transmission at times r(k)=r(0)+kT;
 The deadline of the message packet is a function of the number of
available buffer. With B buffers, the associated deadlines are
d(k)=r(k)+BT.
 The period T is assumed to be an integer number of packet slots;
 Each message contains an integer number C of packets.
 Since the possible task sets under these assumptions (remember

that tasks correspond to messages to be delivered) are only a

subset of all possible task sets, we expect that Ulub is in general
higher than in the task scheduling case (Ulub was computed as the
minimum Uub between all possible task sets fully occupying the
processor).
 Real-Time communication
 The scheduling algorithm used to assign priorities to the packets
is Rate Monotonic: priorities are assigned in an inverse relation
to message periods.
 For a given set of n periodic messages m={m1... mn} , with mj=(Cj,Tj),
we assume that the messages are labelled with decreasing priority, i.e.,
T1≤T2≤... ≤Tn
 The utilization factor of a periodic message mj is defined as Uj=Cj/Tj
 The utilization factor of a set of periodic messages m={m1... m1) is
defined as the sum of individual utilization factors.
 We say that a particular set of messages can be scheduled by a
particular algorithm if, using this algorithms, all the deadlines
for all messages are met.
 Real-Time communication
 A useful lemma regarding the scheduling of a set of periodic
messages is the critical zone lemma due to Liu and Layland.
 Given a set of messages with periods {T1,…,Tn}, where Tn is the longest
period, the time zone from time 0 to Tn is called the critical zone when
all messages are initiated at time zero;
 The critical zone lemma states that if a message set can meet all the
deadlines during the critical zone, then it can meet all its deadlines all the
time.
 Real-Time communication
 As for the standad Rate Monotonic, we want to find scheduling
bound.
 Initially we assume that there is a sufficient number of priority levels and
that message packets are single buffered.
 We aim at finding the bus utilization Ulub of the worst case message set:
if, for a given message set, U is less or equal than Ulub , this is a sufficient
condition for schedulability.
 Real-Time communication
 A set of messages can be categorized in three important ways:
 The length of the longest period;
 The number of distinct periods;
 The number of single packets messages.
 This leads to three distict formulations of the lower bound for
utilization;
 Then, given a message set, one is allowed to categorize the
message set in the way that yields the more convenient Ulub.
 Real-Time communication
 Problem formulation 1: the length of the longest period.
 We consider message sets consisting of m messages with the longest
period n;
 We assume single buffering and sufficient priority levels;
 It can be demonstrated that the worst case is given by single packet
messages with periods p, p+1,..., n-1 and 2p-n single packet messages
with period n, where p=ceil((n+1)/2;
 This yields
 Real-Time communication
 Problem formulation 2: the number of distinct periods.
 We consider message sets with n distinct periods T1<...<Tn, but
otherwise arbitrary (no equal periods);
 We assume single buffering and sufficient priority levels;
 It can be demonstrated that the worst case bound is

U lub (n)  n(21/ n 1)

lim U lub (n)  ln 2  0.69
n
 Real-Time communication
 Problem formulation 3: the number of single packet messages.
 We consider message sets with n single packet messages, but otherwise
arbitrary;
 We assume single buffering and sufficient priority levels;
 It can be demonstrated that the worst case is given by n messages with
periods (T1=n, T2= n+1,..., Tn=2n-1);
 This yields

U lu b (n)  n 1/ i
2n1

lim U lu b (n)  ln 2  0.69

n
 Real-Time communication
 We now investigate the effect of a finite priority granularity for
RM.
 Assume K distinct priority levels and a corresponding priority grid {0,
L1,..., Lk};
 If a period T falls between two grid levels, i.e., Li-1<T≤Li, then the
message will be assigned priority i.
 The maximal message period must be bounded, or else the worst case
utilization can be made to approach 0
 Real-Time communication
 For a finite priority granularity, the worst case utilization bound
approaches 0 as the longest period Tmax, approaches infinity.
 Proof: Fix the value of Lk-1. Since T is unbounded, we must let Lk be infinite.
 All messages with period longer than Lk-1 will be given priority K.
 Since the ties are broken arbitrarily within a single priority level, it is possible
that a message with period N will be given priority higher than a message with
period M, where N > M > Lk-1
 Now if there were M such messages with period N or the period N message
required M slots, then the period M message would miss its deadline.
 The maximum bus utilization of this set of messages (not to miss deadline) is
given by l/M + (M-1)/N.
 When M and N are unbounded. the utilization can be made arbitrarily small.
 Real-Time communication
 We now assume Tmax is finite and equal to Lk
 It is possible to define a measure of the granularity of the grid.
 Let Gi= (Li-1+1)/Li

 Let G= min Gi
 If there is only one period per priority level, then G=1.
 In the case that G=1, Ulub always converged to ln2.
 Otherwise, it holds

R(G) 1/ 2  G  1
U lub (G)   , R(G)  ln(2G) 1 G
 G 0  G  1/ 2

 The upper bound above reduces to the usual result when G=1.
 Real-Time communication
 The effect of multiple buffering.
 Up to now we have investigated scheduling bounds when message packets are
single buffered: we now investigate the effect of multiple buffering.
 When B=1, the deadline of the message is the initiation time of the next

messge;
 When B=2, the deadline becomes the initiation time of the third message.

 With multiple buffers, we expect improvements in the scheduling potential: the

scheduling potential becomes 1 when the number of buffer tends to infinite,
since in this case there are no more deadlines to be met.
 As in the case B=1, we can formulate the problem in different
ways when B>1, on the basis of:
 The number of distinct periods;
 The length of the longest period;
 Real-Time communication
 Problem formulation 1. The number of distinct periods;
 We consider message sets with n distinct periods T1<...<Tn, but
otherwise arbitrary (no equal periods);

U lub (n)  nB((11/ B)1/ n 1)

limU lub (n)  B ln(11/ B)
n

 This result corresponds to the result we already knew for B=1

 Real-Time communication
 Problem formulation 2. The length of the longest period;
 We consider message sets consisting of m messages with the longest
period n.
 It can be demonstrated that the worst case is given by
 T1=floor(nB/(1+B)+1); Ti+1= Ti+1, ; Tm= n
 Ci=B; Cm=(1+B)T1-nB;

U lu b (n)  Bi T 1/ i  (1/ n)[(1  B)T1  nB]

n1

lim U lu b (n)  B ln(11/ B)

n

 This result corresponds to the result we already knew for B=1

 Design problems

 Handling time
 The most common solution is to have an internal timing reference: the
timer interrupts the activity of the CPU with a given frequency, and it
executes the scheduling algorithm (that chooses a task to be executed);
 The smallest time interval recognized by the kernel is referred to as tick
or system quantum (10ms, 1ms, and so on)
 If Q is the temporal quantum and n is the number of ticks stored in a
variable, the time from the system initialization is nQ.
Design problems
 Another possible solutions is that the scheduling algorithm is executed
only in three cases
 When a task terminates its execution (e.g., the scheduling algorithm
is called explicitly by the task itself);
 When a task becomes ready for the next period (e.g., the scheduling
algorithm is called upon expiration of a timer, that has been set by
the task itself after the previous execution);
 When a task is blocked on resources, or it releases resources.
 Design problems
 Overhead in case of a periodic timer
 We consider here how to handle the internal kernel mechanisms (task
queuing, context switch, updating internal data structures, sending
messages, interrupt serving);
 A fundamental factor is the timer interrupt routine, that is executed with
a frequency corresponding to the temporal resolution of the system.
 If Q is the temporal quantum and  is the computational time of the
associated routine, the overhead can be computed as Ut= /Q , and the
effective utilization factor that is available for tasks is
Ueff  Ulub Ut  Ulub   / Q  Ulub Q   / Ulub  / Q

 This poses constraints on the system quantum, which must be higer than
/Ulub otherwise we would have negative values.
 Design problems
 For example, by considering EDF with  =0.1 ms
 If Q = 10 ms, Ueff = 0.99
 If Q = 1 ms, Ueff = 0.9
 If Q = 0.2ms, Ueff = 0.5
 The schedulability test becomes (sufficient conditions)

Ci
U 
n

i 1
 U eff
Ti
Design problems
Ueff(Q) (=0,1ms)

1,20

1,00

0,80

0,60

0,40

0,20

0,00

-0,20

-0,40
 Design problems
 The system quantum Q must be decided when designing the Operating
System
 Small values improve reactivity;
 Big values reduce overhead.
 An example: up to kernel 2.4.xx, the system quantum of Linux was 10ms
on i386 and 1ms on alpha. This mean that we can have an error of 10ms
when taking scheduling decisions.
 When the system call “nanosleep” was requested to suspend a task for
a time longer than 10ms, the CPU chooses another task for execution
(but the accuracy is in the order of tens of milliseconds)
 When the system call “nanosleep” was requested to suspend a task for
a time shorter than 10ms, it uses busy waiting (i.e., the CPU does not
choose another task for execution, but the accuracy is in the order of
microseconds).
 Design problems
 Manual page of nanosleep (Kernel 2.4.xx).
 Design problems

 With the kernel 2.6.xxx the system quantum is 1ms, but still the accuracy is in the
order of few milliseconds (when nanosleep does not work in busy waiting)
 Different research groups are developing alternative systems based on high
precision timers (http://lwn.net/Articles/151793/)
 The real-time extensions of Linux (RTLinux, RTAI, etc.) are based on a different
principle.
 Design problems
 Le commutazioni di contesto espliciti (ad esempio quando un processo si
blocca su un mutex) sono già contati nella durata delle sezioni critiche.
 I cambi di contesto dovuti alla preemption possono essere addebitati ai
processi che la causano o a quelli che la subiscono.
 Nel primo caso, è molto semplice perché un processo può eseguire
preemption solo una volta nel corso di ogni periodo. Si calcola
Ci i
U tot   T
i i

 Nel secondo caso bisogna calcolare il numero di preemption subite

dal task
T  Ci  Ni i
N   ceiling  i 
i
k  Tk 
U tot   T
i i

 (dove Tk sono i periodi dei task a priorità più alta). La seconda

condizione è molto pessimista. Ha il solo vantaggio di non addebitare
i cambi di contesto al task a priorità più alta.