Event-Driven Scheduling

(closely following Jane Lius Book)

Real-Time Systems, 2009

Event-Driven Systems, 1

Hermann Hrtig, TU-Dresden

Principles
Admission: Assign priorities to Jobs
At events, jobs are scheduled according to their priorities
Important properties:
decisions, which job to execute next at EVENTS
(not time instants)
such as releases and completions of jobs
a (timer) interrupt is an (implementation of a) special event
never leaves a resource idle intentionally (greedy)
on line,
scheduling
admission
on line or off line
scheduling must be simple
(otherwise difficult/not possible on line)

Real-Time Systems, 2009

Event-Driven Systems, 2

Hermann Hrtig, TU-Dresden

Restrictions Given Up
some restrictive assumptions of time-driven systems are
given up:
fixed inter-release times
minimum inter-release times
fixed number of rt tasks in systems
real-time and non real-time, number can vary
a priori fairly well known parameters
tasks come and go, overloading, ...

Real-Time Systems, 2009

Event-Driven Systems, 3

Hermann Hrtig, TU-Dresden

Priority Assignment Following Criticality

The more critical a task the higher its priority
T1: (2,0.9) T2: (5,2.3)
T2 more critical than T1
T2

T2
0
2
4
6
8
10
T1 misses deadline in Job 1 and 2/3, unnecessarily ...
T1
0

10

10

T2

Real-Time Systems, 2009

Event-Driven Systems, 4

Hermann Hrtig, TU-Dresden

Important Variants
Static vs dynamic allocation to processors
static:
jobs are assigned to processors once and stay there
dynamic:
jobs migrate
example: one run queue served by all processors
static vs. dynamic priorities
jobs do not change their priorities
static:
(unless new tasks arrive)
priorities are recomputed frequently
dynamic:
e.g., FIFO is dynamic priority scheduling
preemptive or non preemptive
some tasks
all tasks
Real-Time Systems, 2009

Event-Driven Systems, 5

Hermann Hrtig, TU-Dresden

Preemptive vs. Non-Preemptive Scheduling,

Example
2 processors,
Tasks: Notation used below: Ji ,ei
release time of J5 is 4, all others 0; (!)
static priorities, assigned such that:
i < k => Prio(Ji) higher than Prio(Jk)
Tasks can migrate
precedence graph:
J1,3
J2,1
J3,2
J4,2
J5,2
J6,4
J7,4
J8,1
Real-Time Systems, 2009

Event-Driven Systems, 6

Hermann Hrtig, TU-Dresden

Example, executions
P1

J1

0
J2 J3
P2

P1

J1

0
J2 J3
P2

J7

J4
4
J7
J5

J6
8
J8

J4 J5
J6
4
8
J7
J8

Real-Time Systems, 2009

12

J1,3
J2,1
J5,2
J7,4

12

Event-Driven Systems, 7

preemptive

J3,2
J6,4
J8,1

J4,2

non preemptive

Hermann Hrtig, TU-Dresden

Modified Example: release time of J5 = 0

P1

J1

0
J2 J3
P2

J5
4
J4

J6
8
J7

12
J8

}
J1,3
J2,1
J5,2
J7,4

Real-Time Systems, 2009

Event-Driven Systems, 8

non preemptive

J3,2
J6,4
J8,1

J4,2

Hermann Hrtig, TU-Dresden

Which is better?
No general answer known!
If jobs have same release time:
preemptive is better (or equal)in a multiprocessor system if
cost for preemption is ignored
more precise: makespan is better
(makespan = response time of job that completes last)
how much better?
Coffman and Garey:
2 processors:
makespan(non-preemptive) <= 4/3 *
makespan(preemptive)

Real-Time Systems, 2009

Event-Driven Systems, 9

Hermann Hrtig, TU-Dresden

Effective Release Times and Deadlines

Inconsistencies due to precedence relations
a release time given for a job may be later than that of
its predecessor
a deadline may be earlier than of its successor time

Real-Time Systems, 2009

Event-Driven Systems, 10

Hermann Hrtig, TU-Dresden

From Now: use effective ...

Effective Release Time:
of a job without predecessors: the given release time
of a job with predecessors:
max (
given release time,
effective release times of all predecessors)
Effective Deadline:
of a job without successor: the given deadline
of a job with successor:
min (
given deadline,
effective deadlines of all successors)

Real-Time Systems, 2009

Event-Driven Systems, 11

Hermann Hrtig, TU-Dresden

Earliest Deadline First

Assign priorities at run time ...
the earlier the deadline the higher the priority
Theorem:
One processor.
Jobs preemptable.
Jobs do not contend for passive resources.
Jobs have arbitrary deadlines, release times.
Then: EDF is optimal, i.e.
if there is a feasible schedule,
there is also one with EDF

Real-Time Systems, 2009

Event-Driven Systems, 12

Hermann Hrtig, TU-Dresden

EDF Optimality
Proof: (informal)
assume a feasible, non EDF schedule
systematically transform it to an EDF schedule (3 steps)
rk
di
dk
Non
EDF

Ji

Jk

1.

Jk

Ji

2.

Jk

3.

Jk

Real-Time Systems, 2009

Jk
Jk

Jk
Ji

Ji

Event-Driven Systems, 13

Hermann Hrtig, TU-Dresden

Earliest Deadline First, priority assignment:

fixed per job, dynamic at task level:
the nearer the absolute deadline of a job at release time
the higher the priority
T1: (2,0.9) T2: (5,2.3)
T1
0

10

10

T2

Real-Time Systems, 2009

Event-Driven Systems, 14

Hermann Hrtig, TU-Dresden

Latest Release Time (LRT)

Rationale:
no need to complete rt-jobs before deadline
use time fr other activities
Idea:
Backwards Scheduling
Run as late as possible
Use latest possible release times as priority
optimal (analog EDF-Definiton of Optimality)
Example (Precedence Graph):
J1,3 (0,6]

J2,2 (5,8]
0

J3,2,(2,7]
Real-Time Systems, 2009

J1

Event-Driven Systems, 15

J3
4

J2
8

Hermann Hrtig, TU-Dresden

Least Slack Time First / Minimum Laxity First

Slack Time = Laxity:
(time to deadline
- remaining execution time required to reach deadline)
slack time: d - x - t
x
remaining execution time of a job
d absolute deadline
t
current time
dynamic per job, dynamic at task level (see example)
also optimal (analog EDF definition)

Real-Time Systems, 2009

Event-Driven Systems, 16

Hermann Hrtig, TU-Dresden

Least Slack Time First

two versions:
strict:
slacks are computed at all times
Each instruction (prohibitively slow)
Each timer tick
non-strict:
slacks computed only at events (release and completion)
scheduler checks slacks of all ready jobs and reorders queue

Real-Time Systems, 2009

Event-Driven Systems, 17

Hermann Hrtig, TU-Dresden

Non-Strict LST Example

T1: (2,0.75) T2:(5,1.5)

T3: (5.1,1.5)

1.5 1.5
0

12

16

t=0

all Jobs released

T1,J1:1.25
T2,J1: 3.5
T3,J1: 3.6
d.h. T2,J1 higher priority than T3,J1

t=2

T1,J2 released
T1,J2:1.25
T2,J1: 2.75 T3,J1: 1.6
d.h. T2,J1 lower priority than T3,J1

t=2.75 T1,J2 completed

T1,J2:
T2,J1: 2
Real-Time Systems, 2009

20

24

28

T3,J1: 0.85

Event-Driven Systems, 18

Hermann Hrtig, TU-Dresden

EDF and Non - Preemptivity

Job: (release time, execution time, deadline)
J1: (0,3,10) J2: (2,6,14) J3: (4,4,12)
release time job 3

EDF

J3 deadline missed

J1
0

4
J1

feasible
0

J3

J2
8
J3
4

12
J2

12

EDF is not optimal if jobs are not preemptable.

Real-Time Systems, 2009

Event-Driven Systems, 19

Hermann Hrtig, TU-Dresden

EDF and Multiple Processors

Job: (release time, execution time, deadline)
J1: (0,1,2) J2: (0,1,2) J3: (0,5,5)
deadline missed
P1

J1
0

P2

J3
4

P1

J2
0

J1 J2
J3

P2
4

EDF

feasible

easy for time driven schedulers

EDF is not optimal for Multiprocessors.
Real-Time Systems, 2009

Event-Driven Systems, 20

Hermann Hrtig, TU-Dresden

Scheduling Anomaly
release / deadline / execution
J1:
0
/
10
/
5
J2:
0
/
10
/
[2,6] varies
J3:
4
/
15
/
8
J4:
0
/
20
/
10
increasing priorities:
i < k => Prio(Ji) higher than Prio(Jk)
2 processors, preemptable but not migratable
intuitive approach:
check for worst case(a) and best case(b) execution times
and be confident ...
Real-Time Systems, 2009

Event-Driven Systems, 21

Hermann Hrtig, TU-Dresden

Scheduling Anomaly, cont

a

{
{

P1
P2
P1

P2
P1
P2

Real-Time Systems, 2009

J3

J1
0

J2
0

12

16

20

J4
4

12

16

20

12

20

J3
8

16
J4

12

16

20

12

20

J3
8

16
J4

12

16

20

J1
0
J2

J4

0
J1
0
J2
0

4
J4
4

Event-Driven Systems, 22

Hermann Hrtig, TU-Dresden

Scheduling Anomaly on One Processor

Job: (release time, execution time, deadline)
J1: (0,3-4,10) J2: (2,6,14) J3: (4,4,12)
Not preemptable
release time job 3
E1=3
0

J1
2

J1
2

E1=4

J2
6

J3
6

Real-Time Systems, 2009

deadline missed
J3

10

12

14

16

18

20

22

12

14

16

18

20

22

J2
8

10

Event-Driven Systems, 23

Hermann Hrtig, TU-Dresden

Predictable/Sustainable Execution
Informal definition:
Given a set of periodic tasks with known minimal and
maximal execution times and a scheduling algorithm.
A schedule produced by the scheduler when the
execution time of each job has ist maximum (minimum)
value is called a maximum (minimum) schedule.
An execution is called predictable, if for each actual
schedule the start and completion times for each job are
bound be those of the minimum and maximal
schedules.

Real-Time Systems, 2009

Event-Driven Systems, 24

Hermann Hrtig, TU-Dresden

Predictable Execution
The execution of every job in a set of independent,
preemptable jobs with fixed release times is predictable
when scheduled in a priority driven manner on one
processor.

Real-Time Systems, 2009

Event-Driven Systems, 25

Hermann Hrtig, TU-Dresden

Validation Algorithms
... determine whether all jobs meet their deadlines
correct or not
accurate or not
overly pessimistic
overly optimistic

Real-Time Systems, 2009

Event-Driven Systems, 26

Hermann Hrtig, TU-Dresden

Assumptions for Next Set of Algorithms

Periodic set of tasks with these properties:
Tasks are independent
one processor
no aperiodic or sporadic tasks
preemptable, context switch is negligibly small
period = minimum inter-release times (not fixed)
Since tasks are independent,
tasks can be added (if admitted) and deleted at any time
without causing deadline misses.

Real-Time Systems, 2009

Event-Driven Systems, 27

Hermann Hrtig, TU-Dresden

Priority Assignment
fixed priority:
fixed for task (and jobs) relativ to other tasks
dynamic priority:
priority of tasks changes at release and completion
times in relation to other tasks
fixed per job
dynamic per job

Real-Time Systems, 2009

Event-Driven Systems, 28

Hermann Hrtig, TU-Dresden

Rate Monotonic Scheduling

fixed priority:
the shorter the period the higher the priority
(rate: inverse of period)
example: T1: (4,1) T2: (5,2) T3: (20,5)

Real-Time Systems, 2009

12

16

Event-Driven Systems, 29

20

Hermann Hrtig, TU-Dresden

Deadline Monotonic Scheduling

fixed priority:
the shorter the relative deadline the higher the priority
example: (,P,e,D)
T1: (50,50,25,100) T2: (0,62.5,10,20) T3: (0,125,25,50)
2.5
0

1.25 1.25
40
80

2.5
120

2.5 X
40
80

2.5
120

2.5

2.5
160

2.5
200

240

DM

2.5
160

2.5
200

240

RM

Conclusion (no proof): DM better than RM if D arbitrary

Real-Time Systems, 2009

Event-Driven Systems, 30

Hermann Hrtig, TU-Dresden

(More) Comparison Criteria

Optimality
Validation
Schedulable Utilization(SU) of an algorithm:
a scheduling algorithm can feasibly schedule any set of
periodic tasks on a processor
if /p SU
SU: the higher the better
dynamic priority schedulers better than fixed priority
predictability in the presence of overload:
in fixed priority systems it is possible to predict which
tasks are affected due to overruns

Real-Time Systems, 2009

Event-Driven Systems, 31

Hermann Hrtig, TU-Dresden

Priority-Driven Scheduling of Periodic Tasks

To do:
admission (required before new tasks are admitted)
priority assignment (off line / on line)
selection of next task (on line)
restrictions (whether they apply or not )
dependencies (precedence, sharing)
multiple processors
aperiodic, sporadic
achievable resource utilization: U= e/p

Real-Time Systems, 2009

Event-Driven Systems, 32

Hermann Hrtig, TU-Dresden

EDF and Multiple Processors

Job: (release time, execution time, deadline)
J1: (0,1,2) J2: (0,1,2) J3: (0,5,5)
deadline missed
P1

J1
0

P2

J3
4

P1

J2
0

J1 J2
J3

P2
4

EDF

feasible

easy for time driven schedulers

EDF is not optimal for Multiprocessors.
Real-Time Systems, 2009

Event-Driven Systems, 33

Hermann Hrtig, TU-Dresden

Another Multiprocessor Example

m processors, m+1 tasks
> 0, m*2 < 1, small
Ti, i=1..m:
Period 1,
execution time: 2
T m+1:
Period 1+ , execution time: 1
scheduler:
allocation:

priority (edf or shortest period first)

dynamic

discuss !
Pathological cases, mostly dynamic performs better
very hard to analyze for worst case

Real-Time Systems, 2009

Event-Driven Systems, 34

Hermann Hrtig, TU-Dresden

EDF and Overload, examples

T1: (2,1) T2: (5,3) U=1.1

T1 misses

T1: (2, 0.8) T2: (5,3.5) U=1.1

T2

T1 und T2 miss

2.3
0
4
8
No easy way to determine which jobs miss deadline ...

Real-Time Systems, 2009

Event-Driven Systems, 35

Hermann Hrtig, TU-Dresden

EDF and Overload, one more example

T1: (2, 0.8) T2: (5, 4.0) U=1.2
Missed deadline
T1
0

10

6
8
Missed deadline

10

T2

J2,1 continues to execute after deadline and ...

causes J1,3 to miss the deadline

Real-Time Systems, 2009

Event-Driven Systems, 36

Hermann Hrtig, TU-Dresden

Utilization: RM ./. EDF

T1: (2,1)
U=1

EDF

RM

T2: (5,2.5)

1.5
0

12

12

RM
not
optimal
in general

T2 misses deadline
Real-Time Systems, 2009

Event-Driven Systems, 37

Hermann Hrtig, TU-Dresden

Optimality of Fixed Priority Schedulers

T: peridodic tasks, independent, preemptable, one proc.
Deadline Monotonic:
relative deadlines <= periods, in phase
if there is any feasible fixed priority schedule for T,
then Deadline Mononotic is feasible as well
Rate Monotonic:
relative deadlines = periods
simply periodic, i.e.
for all pairs of tasks i,j: if Pi <= Pj holds Pj = n * Pi
RM is schedulable iff U <= 1 (cmp. EDF)

Real-Time Systems, 2009

Event-Driven Systems, 38

Hermann Hrtig, TU-Dresden

Some Schedulable Utilization(SU) Results

indep. tasks,
preemptable,
relative deadline=period,
one processor
N Number of Tasks
EDF: SU = 1
RMS: SU = n (2 1/n -1 )

RMS (simply periodical, D

Real-Time Systems, 2009

ln(2)

P): SU = 1

Event-Driven Systems, 39

Hermann Hrtig, TU-Dresden

Schedulibility Test for Fixed(!) Priority

(case where jobs must complete before end of period)
Critical Instant Analysis / Time Demand Analysis:
critical instant for task Ti:
one of the jobs of Ti is released at same time with a job in
every higher priority task ...
It is sufficient to check a schedule for the critical instant for
the longest envolved period

Real-Time Systems, 2009

Event-Driven Systems, 40

Hermann Hrtig, TU-Dresden

(Fixed Prio) Schedulibility and Blocking

Ti may have to wait for
non-preemptable, lower priority task
bi:
longest non-preemptable portion of all lower prio. Jobs
Schedulability for all tasks Ti with fixed priority scheduler x
SUx(i):
Schedulable Utilisation for scheduling method x with i tasks:
Ui = e1/p1 + e2/p2 ... ei/pi
Ui + bi/pi <= SUx(i)

Real-Time Systems, 2009

Event-Driven Systems, 41

Hermann Hrtig, TU-Dresden

Non Negligible Context Switch Time

For Job level fixed priority schedulers ... :
i.e. each job preempts at most one other job
2 context switches:
release (when it preempts other)
completion
include CS overhead in wcet:
WCETi := WCETi_original + 2CS

Real-Time Systems, 2009

Event-Driven Systems, 42

Hermann Hrtig, TU-Dresden

(Fixed Prio and) Limited Priority Levels

Required: Mapping of
Scheduling-Priorities: 1 ... n to

Operating System Priorities: 1, 2, ...

Jobs running with same OS-Prio but different Sched-Prio use:
FIFO, Round Robin, ...
Schedulibility loss ?
Notation: as grid on Scheduling Priorities
Example:
10 scheduling priorities, 3 OS priorities
possible mapping: 1 =3, 2 = 8,3 = 10
Interpretation:
0,1,2,3 mapped to 1, 4,5,6,7,8 to 2, 9,10 to 3
How is Schedulibility Test affected?

Real-Time Systems, 2009

Event-Driven Systems, 43

Hermann Hrtig, TU-Dresden

(Fixed Prio and) Limited Priority Levels

Mappings:
uniformly distributed:
k=n/m
Scheduling Priority X mapped to |X/m|*k
constant ratio:
keep ( i-1 +1) i as equal as possible

Real-Time Systems, 2009

Event-Driven Systems, 44

Hermann Hrtig, TU-Dresden

Schedulilibility Loss
Rate Monotonic, large n ...
g = min( 1 +1) /
SURM = ln(2g)+1-g
relative schedulibility(rs): relation to ln(2)
example:
n = 100000, m = 256
rs= 0.9986
=> 256 priorities is it !
Real-Time Systems, 2009

Event-Driven Systems, 45

Hermann Hrtig, TU-Dresden

12

16
1.25
2.5

20

24

28

1.5

6.5

Real-Time Systems, 2009

Event-Driven Systems, 46

Hermann Hrtig, TU-Dresden