REAL TIME SYSTEMS

9/7/15

Real Time Systems

Real Time System

Those systems in which the correctness
of the system depends not only on the
logical result of computation, but also
on the time at which the results are
produced.
Example Flight Control System
All tasks in that system must execute on
time

9/7/15

Real Time Systems

And Few More Examples

Chemical and nuclear plant control

Control of complex production processes
Railway reservation systems
Automotive applications
Environmental acquisition and monitoring
Telecommunication systems
Industrial automation
Robotics
Military systems
Space missions

9/7/15

Real Time Systems

Real Time System

In General: any system where a timely
response by the computer to external stimuli is
vital
Timely Deadline
Hard/soft RTS

9/7/15

Real Time Systems

Soft Vs Hard RTS!!

Soft real-time system : If the
consequences consist of a degradation of
performance, but not failure
e.g.- time adjusting system on computers over
the network, video game etc..

Hard real-time system : If the

consequences are system failure and
catastrophic result
e.g. emergency patient
management system in5
Real Time Systems
hospitals

9/7/15

RTS CHARACTERISTICS
Time constraints : Deadlines
New Correctness Criteria : logical correctness
of results + time constraints

Embedded: An embedded computer system is

physically embedded in its environment and often
controls it

Safety Criticality: failure can cause severe

damages!!
9/7/15

Real Time Systems

RTS: Common Terminologies

Release time: The time at which all the data
required to begin execution of the task are available
Deadline:
The time by which the task must
complete its execution
Absolute: Time 0 to
the actual instant of Deadlines
occurrence
Relative: Time of arrival to the corresponding deadlines
occurrence

Response time: The time duration from the

occurrences of the event generating the task to the
time the task produces its result
9/7/15

Real Time Systems

Issues
Architecture: Is the architecture suitable?
safety
reliability
fault- tolerance

Operating system : Is the Operating System

suitable?

9/7/15

Task assignment and scheduling

Communication protocol
Failure management and recovery
Interrupt Latency

Real Time Systems

Allocation And Scheduling Issue

Given:

a set of tasks
task precedence constraints
resource requirements
task characteristics
Deadlines

Objective: to devise a feasible allocation/schedule

9/7/15

Real Time Systems

Task Precedence
A task is said to precede another task, if :
the first task must complete before the second task can
start

If task Tis output is needed as input by task Tj,

then task Tj is constrained to be precede by task
Ti
Precedence constraints can be represented by
means of a precedence graph

9/7/15

Real Time Systems

10

Real Time Task Characteristics

Three types:
A. Periodic - Task is released periodically
B. Sporadic

9/7/15

These tasks may be released at any time instant,

but a minimum separation exists between releases
of consecutive instances of the same sporadic task
Can be modeled by periodic tasks with periods
equal to the minimum separation; BUT.. Unlike
periodic tasks, sporadic tasks are released
irregularly or may not be released at all

Real Time Systems

11

Real Time Task Contd.

C. Aperiodic

9/7/15

Tasks which are not periodic and which also have no

upper bound on their invocation rate

Can arise at random instants

Minimum separation
instances may be 0

between

Real Time Systems

two

consecutive

12

Scheduling Algorithms
Uniprocessor, Multiprocessor Scheduling
Uniprocessor:
Rate Monotonic,
Deadline First, Deadline Monotonic etc.

Earliest

Multiprocessor: Utilization Balancing, Next-fit,

Bin-packing etc.

9/7/15

Real Time Systems

13

Scheduling Algorithms :
Classification
Preemptive:
The running task can be interrupted at any time
to assign the processor to ANOTHER task,
according to a predefined policy

Non- Preemptive:
a) With Non- Preemptive algorithms, a task, once
started, is executed by processor until
completion
b) All scheduling decisions taken after this tasks
execution
9/7/15

Real Time Systems

14

Classification Contd.
Static: sch. Decisions are based on fixed
parameters, assign to tasks before their activation

Dynamic: dynamic parameters, may change

during sys. Evolution
Offline : execution on entire set of tasks before
actual task activation
Online: sch. Decisions are taken at RUNTIME every
a new task enters the sys or, when a running task
terminates
9/7/15

Real Time Systems

15

Classification Contd.
Optimal: minimizes some given cost function
defined over the task set.
Heuristic:
a) Searches for a feasible schedule Using an OBJECTIVE
FUNCTION(Heuristic Function)
b) Do NOT guarantee to find an optimal schedule

9/7/15

Real Time Systems

16

Scheduling AnOMaLiEs
In General / Fast Computing :
Increase of computational Power in the supporting
Hardware always RESULTS an Improvement on the
performance of a task set

In Real Time computing:

????

9/7/15

Real Time Systems

17

NO!!!

I.

Anomalies like this have been first described by

Graham in 1976
II. are refer to task sets with precedence constraints
and executed in Multi-processor environment
9/7/15

Real Time Systems

18

Uniprocessor Algorithms
RM
EDF
DM
EDD
LDF
And few more

Real Time Systems

Rate Monotonic (RM) Algorithm

An
Optimal
Staticscheduling algo

priority

Uniprocessor

The task set consists of

Periodic tasks
Pre-emptible tasks

whose deadlines = the tasks periods

Task priorities are static and inversely related
to their periods

9/7/15

Real Time Systems

20

RM (Rate Monotonic)
Optimal static-priority scheduling
It assigns priority according to period
A task with a shorter period has a higher
priority
Executes a job with the shortest period

T1(4,1)
T2(5,2)
T3(7,2)
9/7/15

10

15

10

15
21

RM (Rate Monotonic)
Executes a job with the shortest period

T1(4,1)
T2(5,2)
T3(7,2)
9/7/15

10

15

10

15
22

RM (Rate Monotonic)
Executes a job with the shortest period
Deadline Miss !
T1(4,1)
T2(5,2)
T3(7,2)
9/7/15

10

15

10

15
23

Response Time
Response time
Duration from released time to finish time

T1(4,1)
T2(5,2)
T3(10,2)
9/7/15

10

15

10

15
24

Response Time
Response time
Duration from released time to finish time

Response Time
T1(4,1)
T2(5,2)
T3(10,2)
9/7/15

10

15

10

15
25

Response Time
Response Time (ri)

ri
ri ei
ek

TkHP (Ti ) pk

HP(Ti) : a set of higher-priority tasks than Ti

T (4,1)
1

T (5,2)
2

T (10,2)
3
9/7/15

10

10
26

RM - Schedulability Analysis
Real-time system is schedulable under RM
if and only if ri pi for all task Ti(pi,ei)

9/7/15

27

RM Utilization Bound
Real-time system is schedulable under RM
if
Ui n (21/n-1)

9/7/15

Liu & Laylands Theorem

28

Necessary And Sufficient Condition

For RM-schedulable
Necessary condition: A set of periodic real
time tasks would not be RMA Schedulable unless
they satisfy the following condition:
U

Sufficient Condition: If the task set is such that

the processor utilization is Less Than Equal To
n(21/n 1)
(This is known as Liu and Laylands condition)

then the task set is definitely RM-schedulable

i.e.,

9/7/15

Real Time Systems

29

RM Scheduling
Let:- e:: execution time; p:: period such that p1 p2 . pn
Start with n = 2: T1 and T2 ; so that total utilization

U=

= (e1/p1) + (e2/p2) 2(21/2 1),

0.824

Similarly, for n=3:

U= (e1/p1) + (e2/p2) + (e3/p3)
0.78

3(21/3 1)

then the tasks are RM-schedulable

9/7/15

Real Time Systems

30

RM Scheduling - Example
T1(1,4), T2(1,5), T3(1,10)

satisfied)

U= Ui = 1/4 + 1/5 + 1/10

= 0.55 ( 1; therefore, necessary condition

Now,
= 3 (21/3-1) 0.78
Since, U (0.55) is 0.78, So sufficient condition(Liu and Laylands
condition )also satisfied

Thus, {T1, T2, T3} is schedulable under RM

9/7/15

Real Time Systems

31

RM Utilization Bound
Real-time system is schedulable under RM if
Ui n (21/n-1)

9/7/15

32

Preemptive Earliest Deadline

First (EDF) Algorithm

Optimal
Dynamic-priority
scheduling algo

Always executes the

deadline is the earliest

task

Uniprocessor

whose

absolute

Priorities changes depending on the closeness of

their absolute deadline
A special
algorithm
9/7/15

case

of

Deadline

Real Time Systems

Monotonic

33

Preemptive EDF Contd.

Assumptions:
No task has any non-preemptive section and the
cost of preemption is negligible
Only processing requirements are significant,
memory, I/O and other resource requirements are
negligible
All tasks are independent;
precedence constraints
Tasks need not be periodic
9/7/15

Real Time Systems

there

are

no

34

EDF (Earliest Deadline First)

T1(4,1)
T2(5,2)
T3(7,2)
9/7/15

10

15

10

15
35

EDF (Earliest Deadline First)

Executes a job with the earliest deadline

T1(4,1)
T2(5,2)
T3(7,2)
9/7/15

10

15

10

15
36

EDF (Earliest Deadline First)

Executes a job with the earliest deadline

T1(4,1)
T2(5,2)
T3(7,2)
9/7/15

10

15

10

15
37

EDF (Earliest Deadline First)

Executes a job with the earliest deadline

T1(4,1)
T2(5,2)
T3(7,2)
9/7/15

10

15

10

15
38

EDF (Earliest Deadline First)

Optimal scheduling algorithm
if there is a schedule for a set of real-time
tasks,
EDF can schedule it.
T1(4,1)
T2(5,2)
T3(7,2)
9/7/15

10

15

10

15
39

EDF Summary

Optimal Dynamic-priority Uniprocessor scheduling

algo

Always executes the task whose absolute deadline is

the earliest
Priorities changes depending on the closeness of their
absolute deadline
A special case of Deadline Monotonic algorithm

9/7/15

40

EDF Utilization Bound

Real-time system is schedulable under EDF
if and only if
Ui 1

Liu & Layland Theorm

Necessary as well as sufficient condition??

9/7/15

41

Schedulability Test
U=

P = lcm (P1Pn)
Let:
hT(t) be the SUM of the execution times of all
tasks in set T whose absolute deadlines are less
than t
9/7/15

Real Time Systems

42

Schedulability Test Contd.

A task set of n tasks is not EDF feasible If
i) U > 1 or
ii) There exists

such that hT(t) > t.

9/7/15

Real Time Systems

43

EDF Overload Conditions

Domino efect during overload conditions
Example: T1(4,3), T2(5,3), T3(6,3), T4(7,3)
Deadline Miss !

T1
0

T2
3

T3 T4
5 6 7

Better schedules :

T1
0
9/7/15

T3
3

5 6 7

T1
0

T4
3

5 6 7
44

Preemptive EDF Contd.

Example:
Aperiodic tasks:

t = 0:

T1 arrives, starts execution

Tas Arriva Executi Abs.

tl Time
= 4: on T2 arrives,
k
Deadli preempts T1
Time
newaits
t = 5:
T3
arrives,

t =7:
T2 completes and T3 starts
10
30
execution

T1

T2

t = 17:
execution
T3
5
10
t = 23:
9/7/15

10

T3 completes and T1

starts

25

T1 completes
Real Time Systems

45

EDF- Example
Example: Periodic tasks:
Two tasks: T1(2,5) and T2(4,7)
U=?
Schedulable Under :
RMA?
EDF?

Scheduled diagram from 0 to 35?

9/7/15

46

Example contd.
Schedule under EDF

1a

2a

1b

2
22

9/7/15

5
25 26

2b
6 7
28

2
c

1c
8

10

1d
12

2c

1e
14

15

2d
17

1f
20 21

47

RM vs. EDF
Rate Monotonic
Simpler implementation, even in systems
without explicit support for timing constraints
(periods, deadlines)
Predictability for the highest priority tasks
EDF
Full processor utilization
Misbehavior during overload conditions

9/7/15

48

Deadline Monotonic Algorithm

Static priority algorithm
For those tasks having Period Relative
Deadline
Assigns priorities to tasks according to
their
deadline
. Relativ Priori
Task relative
Releas Period
Executi
e Time

on
Time

e
deadli
ne

ty

T1

50

50 (1)

25

100

T2

62.5
(2)

10

20

T3

125 (3)

25

50

9/7/15

Real Time Systems

49

DM Algorithm Contd.
When the relative deadline of every task is
proportional to its period, RM and DM algorithms
are identical
When the relative deadlines are arbitrary, DM
algorithm performs better
DM can produce a feasible schedule when RM
algorithm fails, While RM algorithm always fails
when the DM algorithm fails

9/7/15

Real Time Systems

50

APERIODIC TASK SCHEDULING

Deals with scheduling of Real Time APERIODIC
tasks on a single machine environment
To facilitate the description of Aperiodic
Scheduling problems: Graham proposed a
Notation:

//
Notation Classifies all algorithms using these 3
fields
9/7/15

Real Time Systems

51

Notation //
: describes machine environment on which task
set has to be scheduled(Uniprocessor, multiprocessor)

: describes TASK and RESOURCE

characteristics(preemptive Vs. Non- Preemptive ,
Independent Vs. Precedence constraint, SYNCHRONOUS
Activations etc.)

: describes the optimality criterion(performance

measure)

9/7/15

Real Time Systems

52

Notation //
Example:
1/prec/Lmax : denotes the problem of scheduling a set of
tasks on a Uniprocessor machine with precedence
constraints and the objective is to minimize the maximum
lateness
If no additional constraints are indicated in the second field then ,
preemption is allowed at any time and tasks have arbitrary arrivals

2/sync/ latei : denotes the problem of scheduling a set of

tasks on a Two- processor machine. Tasks have synchronous
arrival times and Do NOT have other constraints. the objective
is to minimize the number of late tasks
3/no_preem/ Ri : ???
9/7/15

Real Time Systems

53

Jacksons Algorithm
The Problem considered by this algo. is:
1/sync/Lmax
Here:
All tasks consists of a single job, have syn. arrival times,
BUT can have diferent execution times and deadlines
Tasks are independent, cant have precedence relations
and cant share resources in exclusive mode

A simple algo. that solves this Problem was found

by Jackson in 1955:
It is called as Earliest Due Date Algorithm and
can be expressed by the following rule:
9/7/15

Real Time Systems

54

Jacksons Rule : EDD Algorithm

Given a set of n independent
tasks:
any algorithm that executes the tasks
in order of increasing deadlines is
OPTIMAL with respect to Minimizing
the MAXIMUM Lateness

9/7/15

Real Time Systems

55

EDD Algorithm
Consider a set of 5 tasks, simultaneous activated
at t=0:
J1

J2

J3

J4

J5

ei

Di

10

Scheduling the tasks produced by EDD algo:

1. The maximum lateness = -1 : due to J4(completes a
unit of time before its deadline)
2. Since the lateness is negative: we can conclude that all
tasks have been executed within their deadlines
9/7/15

Real Time Systems

56

EDD Contd.
Note:
The optimality of EDD algo. CAN NOT Guarantee
the Feasibility of the schedule for a task set.
It ONLY guarantees that:
if there exists a feasible schedule for a task set,
then EDD will Find it

9/7/15

Real Time Systems

57

Scheduling With Precedence Constraints

Latest Deadline First(LDF) Algorithm
Problem : 1/PREC,SYNC/Lmax
Given:
a set J of tasks

a direct acyclic graph(DAG) describing tasks precedence

relations

Among the tasks without successors or whose

successors have all been selected, select the task
with the latest deadline
ii. Remove this task from the precedence graph and put it
into a stack
i.

9/7/15

Real Time Systems

58

LDF Contd.
iii. Repeat until all tasks are in the stack
iv. The stack represents the order in which tasks
should be scheduled
.

9/7/15

LDF is optimal

Real Time Systems

59

LDF: Example

Solve the example

construct the LDF schedule
Find Lmax and feasibility of schedule
Now, construct the EDF schedule. Compare.

9/7/15

Real Time Systems

60

Allowing For Precedence And

Exclusion Conditions(PREC)
Relaxing the assumptions:

Tasks are independent and

Tasks are always pre-emptible by other tasks

E.g. Consider a set of tasks with a precedence graph,

which are released at time 0
T1
T2T3
T4T5
T6
9/7/15

Real Time Systems

61

Example Contd.
Ti

Ei

Di

20

21

27

28

Assumption:
Deadline is specified for each task, such that there will be
enough time to execute its children in the task graph by their
deadlines even if a task completes at its deadline

9/7/15

Real Time Systems

62

Algorithm PREC
Tasks are numbered so that D1 D2 D3 Dn
1. Schedule task Tn in the interval , [Dn-en, Dn]
2. While ( all the tasks have not been scheduled),
let A be the set of as-yet-unscheduled tasks all
successors if any, have been scheduled

of whose

Schedule task Tk , k = max { m/ m A} as late as possible

enddo
3. Move the tasks forward to the extent possible keeping their
order of of execution as specified in step 2

9/7/15

Real Time Systems

63

Handling Critical sections

A task that is currently holding the un-sharable
resource is said to be in the critical section
associated with the resource
Binary semaphores can be used so that only one
task can access the critical section
Properly nested: Serialization
Lock S1
Lock S2
Unlock S2
Unlock S1

9/7/15

Real Time Systems

64

Handling CriticalContd.
Assumptions
Once a task starts, it continues until it
finishes
It can be preempted by some higher priority
task
It can be blocked by lower priority task that
holds the lock on a critical section that it
needs

9/7/15

Real Time Systems

65

Priority Inversion Problem

When a Lower priority task (TL)blocks Higher
priority task(TH) indefinitely
Can occur in any priority-based preemptive
scheduling scheme
Occurs when circumstances within the system
force a higher priority task to wait for a lower
priority task
Indefinite priority inversion
Occurs when a task of medium priority preempts a task of
lower priority which is blocking a task of higher priority

9/7/15

Real Time Systems

66

Indefinite Priority Inversion: Example

J1, J2, J3 are 3 tasks ( Descending order of priority to
share a processor)
S Critical Section used by J1 and J3

t0 :
J3 begins execution
t1 :
J3 enters S
t2 :
J1 released, it preempts J3 and start executing
t3 :
J1 wants to enter S, S is locked by J3 which is
suspended, J1 is blocked and J3 continues in S
t4 :
J2 is released which preempts J3
t5 :
J2 completes, J3 resumes
t6 :
J3 exits S; J1 preempts J3
9/7/15

Real Time Systems

67

Indefinite Contd.
preempt J3

(try to lock S)
blocked by J3

indefinite
!
blocking

J1
preempt J3

J2

lock S

J3

tim
e
9/7/15

t0
t3

t1
t4

t2

Real Time Systems

68

Solution:
Use of Priority Inheritance Protocol (PIP):
If THigh is blocked by TLow , TLow temporarily inherits
the priority of THigh. When blocking ceases, TLow
resumes its original priority
For previous example of Priority Inversion Problem:
At time t3, when J3 blocks J1, J3 inherits the higher
priority of J1
So, when J2 is released at t4, It can not interrupt J3
As a result , J1 is not indirectly blocked by J2

9/7/15

Real Time Systems

69

Problems in PIP
1. Deadlocks
Due to crossing nested semaphores
2. Long Blocking Delays
Due to
a. Transitive Blocking
Blocking by indirectly involved semaphores which
are accessed in nested form by blocking jobs
b. Chain Blocking
Blocking can occur sequentially whenever
accessing each semaphore

9/7/15

Real Time Systems

70

PIP : Deadlocking Problem Example

Let 2 Tasks: J1 and J2 use Critical Sections S1 & S2 (while
J1 > J2)
J1: Lock S2 LockS1 Unlock S1 Unlock S2
J2: Lock S1 Lock S2 Unlock S2 Unlock S1
t0
t1
t2
t3
t4

:
:
:
:
:
J1,
t5 :

J2 starts execution
J2 locks S1
J1 is initiated, it preempts J2
J1 locks S2
J1 attempts to lock S1 but blocked. Now J2 inherits priority of
starts execution
J2 tries to lock S2, it cannot do so, since J1 has a lock on it

Both T1 and T2 are deadlocked!

9/7/15

Real Time Systems

71

PIP : DeadlockingContd.
J1 = {..., P(S2) ..., P(S1),...,V(S1) ...,V(S2),...}
J2 = {..., P(S1) ..., P(S2),...,V(S2) ...,V(S1),...}

preempt J2

lock
S2

crossing
nested
semaphores

(try to lock
S1)
blocked by J2

J1
lock
S1

(try to lock
S2)
blocked by J1

J2
tim
t0
e

t1

t2

t3

t4

t5
deadlock!

9/7/15

Real Time Systems

72

PIP: Chain Blocking Problem Example

J1 ..., PS1, ..., VS1, ..., PS2, ..., VS2, ...
J2 ..., PS2, ..., VS2, ...
J3 ..., PS1, ..., VS1, ...

(attempt
S1)to lock
blocked by J3 lock
S1

(attempt
S2)to lock
blocked by J2
complete
unlock
lock unlock
S2
S1
S2

J1
preempt J3 lock
S2

unlock
S2

J2

complete

complete
unlock
S1

lock
S1

J3

time

9/7/15 t0

t1

t2

t3

t4

t5

Real
t6Time Systems
t7

t8

t9

t10 t11 t12

t13

73

What Really Happened on

Mars?

9/7/15

Real Time Systems

74

Repeated Resets in Mars Pathfinder

The Mars Pathfinder mission was widely proclaimed as
"flawless" in the early days after its July 4th, 1997
landing on the Martian surface....
But a few days into the mission, not long after Pathfinder
started gathering meteorological data, the spacecraft
began experiencing total system resets, each resulting in
losses of data.
The press reported these failures in terms such as
"software glitches" and "the computer was trying to do
too many things at once"....

9/7/15

Real Time Systems

75

Priority Ceiling Protocol

Goals:
Solve problems of PIP: Prevent deadlocks, transitive
blocking and blocking chains

Basic Idea:
Priority ceiling of a semaphore is:
The priority of the highest priority task that
may use the semaphore

9/7/15

Real Time Systems

76

Priority Ceiling Protocol

Similar to Inheritance except that :
a task can also be blocked from entering

a
critical section(CS) if there exists any semaphore
currently held by some other task whose priority
ceiling is greater than or equal to the priority of T

i.e.,
Additional condition for allowing a job J to start a
new critical section is:
only if Js priority is higher than all priority ceilings of
all the semaphores locked by jobs other than J

9/7/15

Real Time Systems

77

Illustration: Priority Ceiling

Tasks: T1, T2, T3

9/7/15

T1> T2> T3

Real Time Systems

78

PCP Example:

4 real time tasks: J1,J2,J3,J4 Sharing two CS: S1, S2 such that:
S1: J1, J2, J3
S2: J1, J4

P(J1) < P(J2) < P(J3) < P(J4)

Thus, from the given info:
Ceil(S1) = max { P(J1), P(J2), P(J3) } = P(J3)
Ceil(S2) = max { P(J1), P(J4) } = P(J4)

Initial Situation : Task J1 is executing and after some time, it

moves to acquire S1
Since S1 is free, task J1 entered and locked it

After locked, Ceiling of S1 is set (= P(J3))

9/7/15

Real Time Systems

79

PCP Example Contd.

Now,

Situation 1: After some time, J4 Becomes Ready

Since P(J4) > P(J1), J4 preempts J1 and starts execution
After some time, J4 Requests S2
Since P(J4) > Ceil (S1){Note that at present, only S1 is locked}, J4
is granted S2
After locked, Ceil(S2) is now set (= P(J4))
When J4 completes its execution, J1 will get a chance to
execute

Situation 2: After some time, J3 becomes Ready

9/7/15

Since P(J3) > P(J1), J3 preempts J1 and starts execution

After some time, J3 Requests S1
Since P(J3) is NOT Greater Than Ceil (S1), J3 will NOT granted S1
Thus, J3 would be blocked and J1 inherit the priority of J3 and
starts execution
Real Time Systems

80

PCP Advantage #1

Prevent deadlocks :
J1 = {..., P(S0) ..., V(S0),...}
J2 = {..., P(S1) ..., P(S2),...,V(S2) ...,V(S1),...}
J3 = {..., P(S2) ..., P(S1),...,V(S1) ...,V(S2),...}
lock S0

nested crossing
semaphores

unlock S0
complete

preempt J3

J1

lock S2
preempt J3

J2

(attempt to lock
S1)
blocked by J3

lock S2

unlock S2
unlock S1
complete

lock S1

lock S1unlock S1 unlock S2

complete

J3

time

9/7/15 t 0

t1

t2

t3

t4

t 5 Real
t 6 Time
t 7 Systems
t8
t9

t10

t11

t12

t13 t14

t15 81

PCP Advantage #2

Prevent transitive blocking :

J1 {..., P(S2) ..., V(S2),...}
J2 = {..., P(S2) ..., P(S1),...,V(S1) ...,V(S2),...}
nested
semaphores
J3 = {..., P(S1),...,V(S1) ...,}
lock S2 unlock S2

preempt J3

complete

J1

lock S1unlock S1
preempt J3

unlock S2
complete

lock S2

(attempt to lock
S2)
blocked by J3

J2
complete

unlock S1

lock S1

J3

time
9/7/15t 0

t1

t2

t3

t4

t 5 Systems
Real Time
t6
t7

t8

t9

t10

t11

t12

t13

82

PCP Advantage #3
Prevent Chain Blocking :

J1 = {..., P(S1), ..., V(S1), ..., P(S2), ...,

V(S2), ...}
J2 = {..., P(S2) , ..., V(S2), ...}
J3 = {..., P(S1) , ..., V(S1), ...}
(attempt
S1)to lock
blocked by J3 lock
S1

unlocklock
S2
S1

unlockcomplete
S2

J1
to lock
preempt J3 (attempt
S2)
blocked by J3

lock
S2

unlock complete
S2

J2
complete

unlock
S1

lock
S1

J3
t0 t1

t2

t3

t4

t5

t6

t7

t8

t9

t10

t11 t12

t13

83

Practice Problem:
S1
S2

9/7/15

T1 T4
T2, T4, T5

P(T1)
P(T2)

Real Time Systems

84

Diferent Types of Priority Inversions

Under PCP

Tasks, sharing a set of resources using PCP, may undergo 3

types of priority inversions:
1. Direct Inversion: Occurs when a higher priority task waits
for a lower priority task to release a resource that it needs
TL
CS

TH

At present, a lower priority task TL is holding a critical section CS

Now, if a higher priority task TH needs this resource, it would

have to wait till TL finishes using CS and release it

Thus a lower priority task DIRECTLY causes a higher priority task

to undergo inversion by holding the resource it needs

9/7/15

Real Time Systems

85

Diferent Types Contd.

2. Inheritance- Related Inversion:
TL

TI

CS
TH

When a lower priority task (TL) is holding a resource and a higher

priority task (TH) is waiting for it

Then, the priority of TL is raised to that of the waiting TH by

implementing PIP

As a result, the Intermediate tasks (TI ) not needing the resource

can not execute due to the raised priority of TL and therefore, TI
undergo Inheritance- Related Inversion
86

Diferent Types Contd.

3. Avoidance- Related Inversion:

In PCP- when a task J request a resource its priority is checked

against all the priority ceilings of all the semaphores locked by
task other than J

Requesting task J is granted the use of the shared resource only

when its priority is greater then the highest Ceiling Value(CSV)

Ceil(S1)= 10
CSV= 10

9/7/15

TL
CS
1

P(TH) = 8

CS
2
TH

Thus, even when a resource that task is requesting is idle, the

requesting task may be denied access to the shared resource if
this requesting tasks priority is less then CSV
Real Time Systems

87

Diferent Types Contd.

A task whose priority is greater then the currently executing
task , but lesser then CSV and needs a shared resource that is
currently not in use, is said to undergo Avoidance- Related
Inversion
Thus, a higher priority task may get blocked for a
resource that is not being used by any of the tasks

shared

Though this restriction might appear too restrictive and

wasteful, it necessarily leads to prevent deadlocks
Therefore, this type of inversion is popularly called DeadlockAvoidance Inversion: blocking is caused due to the Priority
Ceiling rule in order to avoid Deadlocks
9/7/15

Real Time Systems

88

Example:
Inversions

Diferent

Types

of

A systems has 6 Tasks and 3 CS: S1, S2 and S3; such that:
P(T1) > P(T2)> P(T3)>P(T4) >P(T5) >P(T6)
The exact resource requirements of these tasks & the duration(in
msec) for which the tasks needs the resources can be shown as:

T
1

T
2

T
3
30

20

S1

10

T
4
50

S2
10

T
5

40

S3
10

T
6
9/7/15

Real Time Systems

89

Example Contd.
Challenge: Computing the diferent types of inversions that each task
might have to undergo in the worst case
Solution:
The ceiling of any CS S can be calculated as:
Ceil(S) = max ( P{Ti}) ; such that Ti may need S

Thus, Ceil(S1) = max (P{T1, T3, T6}) = P{T1}

Similarly, Ceil(S2) = P{T2}; and Ceil( S3) = P{T3}

One by one for each task, determine the 3 diferent types of

Inversions that each task might sufer, and the duration of the
inversions:

9/7/15

Real Time Systems

90

Example Contd.
a. For task T1:
. T1 can sufer direct- inversion by T3(10 sec due to S1), OR , by T6(10 sec
due to S1)
. T1 will not sufer any inheritance- related inversion or deadlock- avoidance
inversion since it is the highest priority task
b. For task T2:
. T2 can sufer direct- inversion by T4(40 sec due to S2)
. T2 can also sufer inheritance- related inversion on account of T3(10 sec )
when T3 acquired S1 and T1 waits for S1, OR, on account of T6(10 sec )
when T6 acquired S1 and T1 waits for S1
.

9/7/15

T2 can sufer Deadlock- avoidance inversion by T3(10 sec ) when T3

acquired S1and ceiling value of S1 is now set to P(T1). At this moment, if
T2 might request for S2, it is denied access to S2 because presently, the
highest ceiling value(CSV) = P(T1) which is obviously higher then P(T2)
OR, T2 can also sufer Deadlock- avoidance inversion on account of T6(10
sec ) when T6 acquires S1 and ceiling value of S1 is now set to P(T1)

Real Time Systems

91

Example Contd.
c. For task T3:
. Direct inversion: by T6(10 sec due to S1)
. Inheritance- related inversion: on account of T4(40 sec) when T4
acquired S2 and T2 waits for S2, OR, on account of T6(10 sec ) when
T6 acquired S1 and T1 waits for S1
. Deadlock- avoidance inversion: by T4(40 sec), OR, by T6(10 sec )
d. For task T4:
. Direct inversion: T4 will not sufer any direct inversion since it does
not share any resource with a lower priority task
. Inheritance- related inversion: on account of T6(10 sec ) when T6
acquired S1 and T1 waits for S1
. Deadlock- avoidance inversion: by T6(10 sec )

9/7/15

Real Time Systems

92

Example Contd.
e. For task T5:
. Direct inversion: T5 will not sufer any direct inversion since it does not
share any resource with a lower priority task
. Inheritance- related inversion: on account of T6(10 sec ) when T6
acquired S1 and T1 waits for S1
. Deadlock- avoidance inversion: T5 will not sufer any direct inversion
since it does not require any shared resource(CS)
f. For task T6:
. T6 will not sufer any priority inversion, as it is the lowest priority task

Now, constructing the inversion table for

above values:

9/7/15

Real Time Systems

representing

93

Example Contd.
Direct
Avoidance
Task
T2

T2
T3

T3
T4

T4
T5

Inheritance

T5
T6

T6

T2

T3

T4

T5

T6

T1

10

10

T2

40

10

10

10

10

T3

10

40

10

40

10

T4

10

10

T5

10

Inversion Table
9/7/15

Real Time Systems

94

Extending The RM Algorithm:

Lehoczkys Test

RMS theory of Liu and Layland: Utilization bound based

approach
RMS theory of Lehoczky: Time demand based approach

In RM scheduling:
even when a task set fails Liu and Laylands
Test, we should not conclude that it is not schedulable
under RM algorithm. We need to test further to check if the
task set is RM schedulable

A test that can be performed to check whether a task set is

RM schedulable when it fails Liu and Laylands test is the
Lehoczkys Test

9/7/15

Real Time Systems

95

Lehoczkys Test
Lehoczkys test can be expressed as:
A set of periodic real-time task is RM schedulable
under any task phasing, if all the tasks meet
their respective first deadlines under zero
phasing
The Worst Case Response time for a task occurs when it is in
phase with its higher priority tasks

Response Time: (Finishing Time) (Arrival Time or Release

time)
In phase /Zero phase: Two(or more) periodic tasks are said
to be in phase if their first Instances release simultaneously
9/7/15

Real Time Systems

96

Lehoczkys Test
T1{10, 30} and T2{60,120}
P{T1}> P{T2}

T1

T2
10

a)

T1
20

T2

30

40

T1

T2
60

T1 is in
90 phase with T2,
Response Time = 90 msec

T2

b)

T1

80

T2
30

T1

70

T2
50

60

T1 has a 20 msec phase with respect with T2

Response Time = 80 msec

Thus, worst case Response time for a task occurs when it is in

phase with its higher priority task
9/7/15

Real Time Systems

97

Lehoczkys Test: Formal expression

Let:
we have tasks set: {T1 T2 T3 Ti} ; such that P{T1} > P{T2}.... > P{Ti}
Let the task Ti arrives at time t= 0
During the first instance of the task T i , 3 instances of the task T1have
occurred

1Ti
1T1

1T1

1T1

Each time T1 occurs, Ti has to wait since T1 has higher priority then Ti

9/7/15

Real Time Systems

98

Lehoczkys Test: Formal expression

In general:
The exact no. of times that T1occurs within a single instance of Ti
is given by:
[pi / p1]
Since T1s execution time is e1,
The total execution time required by T1 before the deadline of
Ti is:
[pi / p1] e1
This expression can easily be generalized to consider the
execution times of all the tasks having higher priority then
Ti(i.e., T1 T2 T3 Ti-1)
Therefore the time for which Ti will have to wait due to all its
higher priority tasks can be expressed as:
9/7/15

Real Time Systems

99

Lehoczkys Contd.
This is total time required to execute all the tasks with
higher priority then Ti for which Ti would have to wait
Thus, the task Ti would meet its first deadline, if:
ei +

pi

That is,
if the sum of (the execution times of all the higher priority
tasks occurring before Ti s first deadline) and
(the
execution time of the task Ti itself) is less then equal to its
period, then the task Ti would complete before its first
deadline
9/7/15

Real Time Systems

100

Lehoczkys Contd.

In above expression, it is implicitly assumed that the task

periods are equal to their respective deadlines, i.e., pi =
di
when pi < di: the expression need the following
modification:
ei +

9/7/15

di

Real Time Systems

101

Example:

Problem: 3 periodic real time tasks : T1(10, 20), T2(15,

60), T3(20,120) to be run on a uni-processor. Determine
whether the task is schedulable under RMA

Solution:
1. Ordering all tasks acc. to Priority : T1 > T2> T3
2. Try the sufficiency test for RMA Schedulability( Liu and Laylands
Test):
the task set is schedulable if

Ui

3 (21/3-1) 0.78

Ui = (10/20 + 15/60 + 20/120) = 0.91

This is greater then 0.78. Thus, the task set fails Liu and Laylands
test

9/7/15

Real Time Systems

102

Example Contd.
3. Now, try Lehoczkys Test:
. Ordering all tasks acc. to decreasing order of Priority : T1 >
T2> T3
Testing for T1:
since e1 < d1 here, thus T1 would meet its first deadline

Testing for T2:

15 + [60/20] x 10 60
or, 15 + 30 =45 60
This is satisfied. Thus, T2 would meet its first deadline
Testing for T3:
20 + [ 120/20] x 10 + [120/60] x 15
= 20 + 60 + 30 = 110msec
This is satisfied. Thus, T3 would also meet its first deadline

. Since all the tasks meet their respective first deadlines, the
task set is RMA schedulable according to Lehoczkys result
9/7/15

Real Time Systems

103

Practice
3 periodic real time tasks : T1(20, 100), T2(30,
150), T3(90,200) to be run on a uni-processor.
Determine whether the task is schedulable under
RMA.
Use lehoczkys test.

9/7/15

Real Time Systems

104

Handling Overload
Conditions
Problem: scheduling RT tasks in overloading
conditions
overloading conditions: Situations in which the
computational demand requested by the task set
exceeds the time available on the processor, and hence
not all tasks can complete within their deadlines

Types of transient overload condition :

1. Transient overloads due to Activation Overruns:

9/7/15

Due to excessive arrivals of Aperiodic jobs

This type is typical in Event-Triggered systems
In EDF: Arrival of a new task can cause all the previous
tasks to miss their deadlines Domino Effect
Real Time Systems

105

Handling Contd.

(a) Feasible schedule with EDF in normal load condition; (b)

domino efect
9/7/15

Real Time Systems

106

Handling Contd.
2. Transient overloads due to Execution Overruns:

Due to periodic/ Aperiodic tasks that sporadically execute more than

expected
Can occur in both: Event Triggered and Time Triggered systems
Under RM, an overrun in a task Ti does not afect tasks with higher priority,
but any of the lower priority task could miss its deadline
Under EDF: Domino Efect can be feasible

3.Permanent overloads in Periodic systems:

9/7/15

When the total utilization factor of the task set is greater then 1
Can happen either because of:
a. The execution requirements of the task set was not correctly estimated
b. Some unexpected activation of new periodic tasks
c. Some of the current tasks increased their activation rate to react to
some changes in the environment

Real Time Systems

107

Typical Scheduling Schemes

1.Best Effort:
This class includes those algorithms with no prediction for
overload conditions
At its arrival, a new task is always accepted into a ready queue
So the system performance can only be controlled through a
proper priority assignment that takes task s priority values
into account
Task

Ready Queue

Run

2.Guaranteed:
Includes those algorithms with Admission Control, in which
the load on the processor is controlled by an Acceptance Test
executed at each task interval
9/7/15

Real Time Systems

108

Typical Scheduling Contd.

Typically, whenever a new task enters the system, a
Guarantee Routine verifies the Schedulability of the task
set based on the Worst case Assumptions. If the task set
is found to be schedulable, the new task is accepted in the
ready queue; otherwise, it is Rejected
Task

Guarante
e Routine

Ready
Queue

Run
accepted

rejected

3. Robust Scheduling:

9/7/15

Includes those algorithms that separate timing constraints

and Importance by considering 2 different policies: one
for task acceptance and one for task rejection
Real Time Systems

109

Typical Scheduling Contd.

Whenever a new task enters the system, an Acceptance
Test verifies the Schedulability of the new task set based
the worst case assumptions
If the task set is found to be schedulable, the new task is
accepted in the ready queue; otherwise, 1 or more tasks
are rejected based on a diferent policy
Task

Plannin
g

Ready
Queue

Rejection

Scheduling Policy
Run

Policy

Reject
Queue

9/7/15

Real Time Systems

110

The RED Algorithm

Robust Earliest Deadline (RED): A Robust scheduling algo for

dealing with firm aperiodic tasks in overloaded environments
Proposed by Buttazzo and Stankovic
The algorithm synergistically combines many features
including:
Graceful degradation in overloads
Deadline tolerance, and
Resource reclaiming

Advantages:
operates in normal and overload conditions with excellent
performance
able to predict not only deadline misses but also the size of
the overload, its duration, and its overall impact on the
system
9/7/15

Real Time Systems

111

RED Contd.
In RED:
1. Each task Ji{Ci,Di,Mi,Vi) is characterized by 4 parameters:

A worst-case execution time (Cj)

a deadline {Di)
a deadline tolerance(Mi)
an importance value {Vi)

Deadline Tolerance:
The amount of time by which a task is permitted to be late; that is, the
amount of time that a task may execute after its deadline and still produce a
valid result

Useful in many real applications where the deadline timing

semantics is more flexible than scheduling theory generally
permits
E.g.: Robotics and multimedia systems

9/7/15

Real Time Systems

112

RED Contd.
2. The primary deadline plus the deadline tolerance
provides a sort of secondary deadline, and used to
run the acceptance test in overload conditions
NOTE: having a tolerance greater than zero is different than having a
longer deadline

3. Tasks are scheduled based on their primary deadline but

accepted based on their secondary deadline
4. A schedule is said to be strictly feasible if all tasks
complete before their primary deadline, whereas is said to
be tolerant if there exists some task that executes after its
primary deadline but completes within its secondary
deadline
9/7/15

Real Time Systems

113

RED Contd.
5. The guarantee test performed in RED is formulated in
terms of residual laxity
Residual Laxity (Li ): of a task is defined as the interval
between its estimated finishing time (fi) and its primary
(absolute) deadline (Di)
6. Each residual laxity can be efficiently computed using the
result of the following Lemma:
Lemma:
Given a set J = {J1, J2, J3..Jn} of active aperiodic tasks ordered
by increasing primary (absolute) deadline, the residual laxity Li
of each task Ji at time t can be computed as

Li = Li-1 + {Di - Di-1} - Ci{t},

9/7/15

Real Time Systems

114

RED Contd.
where

L0 = 0,
D0 = t (the current time)
Ci{t} is the remaining worst-case computation time of task J i at
time t
Proof:
By definition, a residual laxity is Li = Di- fi.
Since tasks in the set J are ordered by increasing deadlines, task
Ji is executing at time t, and its estimated finishing time is given
by the current time plus its remaining execution time (f1 = t +
C 1)
As a consequence, L1 is given by:

L1 = D1- f1 = D1- t
9/7/15

Real Time Systems

- C1
115

RED Contd.

Any other task Ji, with i > 1, will start as soon as Ji-i
completes and will finish Ci units of time after its start :{fi
= fi-i + Ci}
Hence, we have:
Li = D i- f i
= Di- fi-1 Ci
= Di- {di-1 - Li-1} - Ci
= Li-1 + {Di- di-1} - Ci

9/7/15

Real Time Systems

116