Real-time Scheduling of Aperiodic and

Sporadic Tasks (2)

Advanced Operating Systems

Lecture 5
Lecture outline

• Scheduling aperiodic jobs (cont’d)

• Simple sporadic server

• Scheduling sporadic jobs

!2
Limitations of Deferrable Servers

• Limitation of deferrable servers – they may delay

lower-priority tasks for more time than a periodic
task with the same period and execution time:

Budget replenished Budget replenished

1
Budget
0 Budget exhausted
JA released
TDS=(p=3, e=1)

T1=(φ=2, p=3.5, e=1.5)

T1 blocked for 1.2 units although execution
time of deferrable server is only 1.0 units
T2=(p=6.5, e=0.5)
0 1 2 3 4 5 6 7 8 9

!3
Sporadic Servers

• A sporadic server is designed to eliminate this

limitation
• A different type of periodic server: several different sub-types
• More complex consumption and replenishment rules ensure that a
sporadic server with period pS and budget eS never demands more
processor time than a periodic task with the same parameters

!4
Simple, Fixed-priority, Sporadic Server (1)

• System, T, of independent preemptable periodic

tasks and a sporadic server with parameters (ps, es)
• Fixed-priority scheduling; system can be scheduled if sporadic server
behaves as a periodic task with parameters (ps, es)

• Define:
• TH : the periodic tasks with higher priority than the server (may be empty)
• tr : the last time the server budget replenished
• tf : the first instant after tr at which the server begins to execute
• At any time t define:
• BEGIN as the start of the earliest busy interval in the most recent contiguous sequence of
busy intervals of TH starting before t (busy intervals are contiguous if the later one starts
immediately the earlier one ends)
• END as the end of the latest busy interval in this sequence if this interval ends before t; 

define END = ∞ if the interval ends after t

!5
Simple, Fixed-priority, Sporadic Server (2)

• Consumption rule:
• At any time t ≥ tr, if the server has budget and if either of the following two
conditions is true, the budget is consumed at the rate of 1 per unit time:
• C1: The server is executing
• C2: The server has executed since tr and END < t

• When they are not true, the server holds its budget
!

• That is:
• The server executes for no more time than it has execution budget
• The server retains its budget if:
• A higher-priority job is executing, or
• It has not executed since tr

• Otherwise, the budget decreases when the server executes, or if it idles

while it has budget

!6
Simple, Fixed-priority, Sporadic Server (2)

• Replenishment rules
• R1: When system begins executing, and each time budget is replenished,
set the budget to eS and tr = the current time.
• R2: When server begins to execute (defined as time tf) 

if END = tf then 

te = max(tr, BEGIN)
 te = effective replenishment time
else if END < tf then 

te = tf

The next replenishment time is set to te + pS
• R3: budget replenished at the next replenishment time, unless:
• If te + pS is earlier than tf the budget is replenished as soon as it is exhausted
• If T becomes idle before te + pS, and becomes busy again at tb, the budget is replenished at
min(tb, te + pS)

!7
 Example
T1

T2

TSS

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

Max. blocking time due
 A1: r = 3, e = 1

A1 A2 to sporadic server = 1.5 A3
A2: r = 7, e = 2
T1=(3, 0.5), T2=(4, 1.0), T3=(19, 4.5), Tss=(5, 1.5)

Rate monotonic schedule; simple sporadic server A3: r = 15.5, e = 2

!8
 Example
T1

T2

TSS

A1 A2 A3
Job A1 executes Job A2 released
 Sporadic server is constrained to execute
but no budget for at most 1.5 units out of every 5, due to
Job A1 released,

Budget available
 consumption and replenishment rules
server blocked
but blocked
No budget
No aperiodic jobs

server suspended Job A2 executes

Budget Budget continues to be used


according to rule C2
1.5
1.0
0.5
0.0
Correctness of Schedule

• More complex than a polling server or a deferrable

server, but much easier to prove the system can be
scheduled
!

• Theorem: for the purpose of validating a schedule,

you can treat a simple sporadic server (ps, es) in a
fixed-priority system exactly the same as any other
periodic task Ti with pi = ps and ei = es
• The actual inter-release times of the sporadic server will sometimes be
greater than ps, and their execution times less than es, but this does not
affect correctness

!10
Simple, Dynamic-priority, Sporadic Server

• It is possible to define a simple sporadic server to

operate in a dynamic-priority environment
• E.g., when using EDF or LST scheduling

• Consumption and replenishment rules conceptually

similar to those for a fixed-priority scheduler, with
minor modifications that account for the difference
in scheduling algorithm
• Provides same scheduling guarantees as the simple sporadic server for
fixed-priority schedulers
• A simple sporadic server (ps, es) in an EDF or LST system can be treated
exactly the same as any other task Ti with pi = ps and ei = es when testing
whether the system can be scheduled

!11
Scheduling Sporadic Jobs

• Consider the problem of scheduling sporadic jobs

alongside a system of periodic tasks and aperiodic
jobs
!

• Recall the sporadic job scheduling problem:

• Based on the execution time and deadline of each newly arrived sporadic
job, decide whether to accept or reject the job
• Accepting the job implies that the job will complete within its deadline,
without causing any periodic task or previously accepted sporadic job to
miss its deadline
• Do not accept a sporadic job if cannot guarantee it will meet its deadline

!12
Model for Scheduling Sporadic Jobs

• When sporadic jobs arrive, they are both accepted

and scheduled in EDF order
• In a dynamic-priority system, this is the natural order of execution
• In a fixed-priority system, the sporadic jobs are executed by a periodic
server that performs an acceptance test, and runs the sporadic jobs in
EDF order
• In both cases, no new scheduling algorithm is required

• Definitions:
• Sporadic jobs are denoted by Si(ri, di, ei) where ri is the release time, di is
the (absolute) deadline, and ei is the maximum execution time
• The density of a sporadic job Δi = ei/(di − ri)
• The total density of a system of n jobs is Δ = Δ1 + Δ2 + … + Δn

• The job is active during its feasible interval (ri, di]

!13
Sporadic Jobs in Dynamic-Priority Systems

• Theorem: A system of independent preemptable

sporadic jobs can be scheduled using EDF if the
total density of all active jobs in the system ≤ 1 at
all times
• This is the standard scheduling test for EDF systems, but including both
periodic and sporadic jobs
• This test uses the density since deadlines may not equal periods; hence it
is a sufficient test, but not a necessary test

• What does this mean?

• If we can bound the frequency with which sporadic jobs appear to the
running system, we can guarantee that none are missed
• Alternatively, when a sporadic job arrives, if we deduce that the total
density would exceed 1 in its feasible interval, we reject the sporadic 

job (admission control)
!14
Admission Control for Sporadic Jobs/EDF

• At time t there are n active sporadic jobs, stored in

non-decreasing order of deadline
• The deadlines partition the time from t to ∞ into n + 1 discrete intervals: 

I1, I2, …, In+1
• I1 begins at t and ends at the earliest sporadic job deadline
• For each 1 ≤ k ≤ n, each interval Ik+1 begins when the interval Ik ends, and ends at the next
deadline in the list (or ∞ for In+1)

• The scheduler maintains the total density Δs,k of each interval Ik

• Let Il be the interval containing the deadline d of

the new sporadic job S(t, d, e)
e
• The scheduler accepts the job if

d t
+ s,k 1 Density of new job
for all k = 1, 2, …, l
• i.e. accept if the new sporadic job can be added, without increasing the
density of any intervals past 1

!15
Admission Control for Sporadic Jobs/EDF

• Notes:
• This acceptance test is not optimal: a sporadic job may be rejected even
though it could be scheduled (the result for the maximum utilisation is
based on the density and hence is sufficient but not necessary)
• It is possible to derive a – much more complex – expression taking into
account slack time, that is optimal. Unclear if the complexity is worthwhile.
• This acceptance test assumes every sporadic job is ready for execution
when released
• If this is not the case, must modify the acceptance test to take into account the time when the
jobs become ready, rather than their release time, when testing the intervals to see if their
density exceeds 1

!16
Sporadic Jobs in Fixed-Priority Systems

• Use a sporadic server to execute sporadic jobs in a

fixed-priority system
• The server (ps, es) has budget es units every ps units of time, so the
scheduler can compute the least amount of time available to every
sporadic job in the system
• Assume that sporadic jobs ordered among themselves in EDF
• When first sporadic job S1(t, ds,1, es,1) arrives, there is at least 

⎣(ds,1 − t)/ps⎦⋅es units of processor time available to the server

before the deadline of the job
• ⎣(ds,1 − t)/ps⎦ = number of server periods available

• Therefore it accepts S1 if slack of job s,1 (t) = b(ds,1 t)/ps c es es,1 0

Time available
Execution time

[cont’d]
!17
Sporadic Jobs in Fixed-Priority Systems
• To decide if a new job Si(t, ds,i, es,i) is acceptable when there are n sporadic
jobs in the system, the scheduler first computes the slack σs,i(t) of Si:


 X

 s,i (t) = b(ds,i t)/ps c es es,i (es,k ⇠s,k )

 ds,k <ds ,i

where ξs,k is the execution time of the completed part of the existing job Sk

The job cannot be accepted if σs,i(t) < 0
• As for σs,1(t), but accounting for the already accepted sporadic jobs

• If σs,i(t) ≥ 0, the scheduler then checks if any existing sporadic job Sk with
deadline after ds,i may be adversely affected by the acceptance of Si
• Check if the slack σs,k(t) for each Sk at the time is at least equal to the execution time es,i of Si
(i.e., Si is accepted if σs,k(t) − es,i ≥ 0 for every existing sporadic job Sk with deadline ≥ ds,i)

!
• This acceptance test for fixed-priority systems is more complex than that
for dynamic-priority systems, but is still of reasonable time complexity to
be implemented “on-line”

!18
Practical Usage

• Hybrid sporadic/background server included in real

time extensions to POSIX
• Use the SCHED_SPORADIC scheduling policy
• When server has budget, runs at sched_priority, otherwise runs as a
background server at sched_ss_low_priority
• Set sched_ss_low_priority to be lower priority than real-time tasks, but possibly higher than
other non-real-time tasks in the system

• Also defines the replenishment period and the initial budget after
replenishment
• As usual with POSIX, applicable to fixed-priority systems only

!19
Summary

• Use of sporadic server for scheduling aperiodic

tasks – complex to implement, easy to prove
correctness
• Scheduling sporadic tasks
• In EDF systems – density test for correctness
• In RM systems using sporadic server – complex rules for correctness, but
intuition of behaviour straight-forward

!20