Real-Time Scheduling
Resource Access Control
[Some parts of this lecture are based on a real-time systems course
of Colin Perkins
http://csperkins.org/teaching/rtes/index.html]
1
Current Assumptions
Single processor
Individual jobs
(that possibly belong to periodic/aperiodic/sporadic tasks)
Jobs can be preempted at any time and never suspend
themselves
Jobs are scheduled using a priority-driven algorithm
i.e., jobs are assigned priorities, scheduler executes jobs according to
these priorities
n resources R1, . . . , Rn of distinct types
used in non-preemptable and mutually exclusive manner;
serially reusable
2
Motivation & Notation
Resources may represent:
Hardware devices such as sensors and actuators
Disk or memory capacity, buffer space
Software resources: locks, queues, mutexes etc.
Assume a lock-based concurrency control mechanism
A job wanting to use a resource Rk executes L(Rk ) to lock the
resource Rk
When the job is finished with the resource Rk , unlocks this
resource by executing U(Rk )
If lock request fails, the requesting job is blocked and has to
wait, when the requested resource becomes available, it is
unblocked
In particular, a job holding a lock cannot be preempted by a higher
priority job needing that lock
The segment of a job that begins at a lock and ends at a matching
unlock is a critical section (CS)
CS must be properly nested if a job needs multiple resources 3
Example
J1, J2, J3 scheduled according to EDF.
At 0, J3 is ready and executes
At 1, J3 executes L(R) and is granted R
J2 is released at 2, preempts J3 and begins to execute
At 4, J2 executes L(R), becomes blocked, J3 executes
At 6, J1 becomes ready, preempts J3 and begins to execute
At 8, J1 executes L(R), becomes blocked, and J3 executes
At 9, J3 executes U(R) and both J1 and J2 are unblocked. J1 has higher
priority than J2 and executes
At 11, J executes U(R) and continues executing 4
Priority Inversion
Definition 1
Priority inversion occurs when
a high priority job
is blocked by a low priority job
which is subsequently preempted by a medium priority job
Then effectively the medium priority job executes with higher
priority than the high priority job even though they do not
contend for resources
There may be arbitrarily many medium priority jobs that
preempt the low priority job ⇒ uncontrolled priority inversion
5
Priority Inversion – Example
Uncontrolled priority inversion:
High priority job (J1) can be blocked by low priority job (J3) for
unknown amount of time depending on middle priority jobs (J2)
6
Deadlock
Definition 2 (suitable for resource access control)
A deadlock occurs when there is a set of jobs D such that each
job of D is waiting for a resource previously allocated by
another job of D.
Deadlocks can be
detected: regularly check for deadlock, e.g. search for
cycles in a resource allocation graph regularly
avoided: postpone unsafe requests for resources even
though they are available (banker’s algorithm,
priority-ceiling protocol)
prevented: many methods invalidating sufficient conditions
for deadlock (e.g., impose locking order on resources, force
jobs to release all resources before locking a new one, ...)
See your operating systems course for more information ....
7
Deadlock – Example
Deadlock can result from piecemeal acquisition of resources: classic
example of two jobs J1 and J2 both needing both resources R and R
J2 locks R and J1 locks R
J1 tries to get R and is blocked
J2 tries to get R and is blocked
8
Timing Anomalies due to Resources
Previous example, the critical section of J3 has length 4
... the critical section of J3 shortened to 2.5
... but response of J1 becomes longer! 9
Controlling Timing Anomalies
Contention for resources causes timing anomalies, priority
inversion and deadlock
Several protocols exist to control the anomalies
Non-preemptive CS
Priority inheritance protocol
Priority ceiling protocol
....
10
Non-preemptive Critical Sections
The protocol: when a job locks a resource, it is scheduled with
priority higher than all other jobs (i.e., is non-preemptive)
Example 3
Jobs J1, J2, J3 with release times 2, 5, 0, resp., and with
execution times 4, 5, 7, resp.
11
Non-preemptive Critical Sections
Features:
no deadlock because no job holding a resource is ever
preempted
no priority inversion:
a job Jh can be blocked (by a lower priority job) at release
time
if Jh is executing, then it cannot be blocked by a lower
priority job (because all resources are free)
if a job Jh is blocked, then once the blocking critical section
completes, no lower priority job can block Jh (since all
resources are free)
... thus any job can be blocked only once, at release time,
blocking time is bounded by duration of one critical section
of a lower priority job
Advantage: very simple; easy to implement both in fixed and dynamic
priority; no prior knowledge of resource demands of jobs needed
Disadvantage: every job can be blocked by every lower-priority job
with a critical section, even if there is no resource conflict 12
Priority-Inheritance Protocol
Idea: adjust the scheduling priorities of jobs during resource
access, to reduce the duration of timing anomalies
(As opposed to non-preemptive CS protocol, this time the priority is not
always increased to maximum)
Notation:
assigned priority = priority assigned to a job according to a
standard scheduling algorithm
At any time t, each ready job Jk is scheduled and executes
at its current priority πk (t) which may differ from its
assigned priority and may vary with time
The current priority πk (t) of a job Jk may be raised to the
higher priority πh(t) of another job Jh
In such a situation, the lower-priority job Jk is said to inherit
the priority of the higher-priority job Jh, and Jk executes at
its inherited priority πh(t)
13
Priority-Inheritance Protocol
Scheduling rules:
Jobs are scheduled in a preemptable priority-driven manner
according to their current priorities
At release time, the current priority of a job is equal to its
assigned priority
The current priority remains equal to the assigned priority,
except when the priority-inheritance rule is invoked
Priority-inheritance rule:
When a job Jh becomes blocked on a resource R, the job
Jk which blocks Jh inherits the current priority πh(t) of Jh;
all priorities are updated transitively
Jk executes at its inherited priority until it releases R; at that
time, the priority of Jk returns to its priority πk (t ) at the time
t when it acquired the resource R
(note that πk (t ) may still be an inherited priority)
Resource allocation: when a job J requests a resource R at t:
If R is free, R is allocated to J until J releases it
If R is not free, the request is denied and J is blocked
J is only denied R if the resource is held by another job 14
Priority-Inheritance Simple Example
non-preemptive CS:
priority-inheritance:
At 3, J1 is blocked by J3, J3 inherits priority of J1
At 5, J2 is released but cannot preempt J3 since the inherited
priority of J3 is higher than the (assigned) priority of J2 15
Priority-Inheritance Example
At 0, J5 starts executing at priority 5, at 1 it executes L(Black)
At 2, J4 preempts J5 and executes
At 3, J4 executes L(Shaded), J4 continues to execute
At 4, J3 preempts J4; at 5, J2 preempts J3
At 6, J2 executes L(Black) and is blocked by J5. Thus J5 inherits the
priority 2 of J2 and executes
16
Properties of Priority-Inheritance Protocol
Simple to implement, does not require prior knowledge of
resource requirements
Jobs exhibit two types of blocking
Direct blocking due to resource locks
i.e., a job J locks a resource R, Jh executes L(R) is directly
blocked by J on R
Priority-inheritance blocking
i.e., a job Jh is preempted by a lower-priority job that inherited a
higher priority
Jobs may exhibit transitive blocking
In the previous example, at 9, J5 blocks J4 and J4 blocks J1, hence J5
inherits the priority of J1
Deadlock is not prevented
In the previous example, let J5 request shaded at 6.5, then J4 and J5
become deadlocked
Can reduce blocking time (see next slide) compared to
non-preemptable CS but does not guarantee to minimize
blocking
17
Priority-Inheritance – Blocking Time
z ,k = the k-th critical section of J
A job Jh is blocked by z ,k if Jh has higher assigned priority than J but
has to wait for J to exit z ,k in order to continue
β∗
h,
= the set of all maximal critical sections z ,k that may block Jh
(recall that CS are properly nested, maximal CS which may block Jh is the
one which is not contained within any other CS which may block Jh)
Theorem 4
Let Jh be a job and let Jh+1, . . . , Jh+m be jobs with lower priority than
Jh. Then Jh can be blocked for at most the duration of one critical
section in each of β∗
h,
where ∈ {h + 1, . . . , h + m}.
18
Lemma 5
Jh can be blocked by J only if J is executing within a critical
section z ,k of β∗
h,
when Jh is released
Assume that Jh is released at t and J is in no CS of β∗
h,
at t. We
show that J never executes between t and completion of Jh:
If J is not in any CS at t, then its current priority at t is
equal to its assigned priority and cannot increase. Thus, J
has to wait for completion of Jh as the current priority of Jh
is always higher than the assigned priority of J .
If J is still in a CS at t, then this CS does not belong to β∗
h,
and thus cannot block Jh before completion and cannot
execute before completion of Jh.
Assume that J leaves z ,k ∈ β∗
h,
at time t. We show that J never
executes between t and completion of Jh:
If J is not in any CS at t, then, as above, J never executes
before completion of Jh and cannot block Jh.
If J is still in a CS at t, then this CS does not belong to β∗
h,
because otherwise z ,k would not be maximal. Thus J
cannot block Jh, and thus J is never executed before
completion of Jh. 19
Priority-Inheritance – The Worst Case
20
Priority-Ceiling Protocol
The goal: to furhter reduce blocking times due to resource contention
and to prevent deadlock
in its basic form priority-ceiling protocol works under the
assumption that the priorities of jobs and resources required by
all jobs are known apriori
can be extended to dynamic priority (job-level fixed priority), see later
Notation:
The priority ceiling of any resource Rk is the highest priority of all
the jobs that require Rk and is denoted by Π(Rk )
At any time t, the current priority ceiling Π(t) of the system is
equal to the highest priority ceiling of the resources that are in
use at the time
If all resources are free, Π(t) is equal to Ω, a newly introduced
priority level that is lower than the lowest priority level of all jobs
21
Priority-Ceiling Protocol
The scheduling and priority-inheritance rules are the same as for
priority-inheritance protocol
Scheduling rules:
Jobs are scheduled in a preemptable priority-driven manner
according to their current priorities
At release time, the current priority of a job is equal to its
assigned priority
The current priority remains equal to the assigned priority,
except when the priority-inheritance rule is invoked
Priority-inheritance rule:
When job Jh becomes blocked on a resource R, the job Jk
which blocks Jh inherits the current priority πh(t) of Jh;
also priorities are inherited transitively
Jk executes at its inherited priority until it releases R; at that
time, the priority of Jk returns to its priority πk (t ) at the time
t when it acquired the resource R
(note that πk (t ) may still be an inherited priority)
22
Priority-Ceiling Protocol
Resource allocation rules:
When a job J requests a resource R held by another job, the
request fails and the requesting job blocks
When a job J requests a resource R at time t, and that resource
is free:
If J’s priority π(t) is higher than current priority ceiling Π(t),
R is allocated to J
If J’s priority π(t) is not higher than Π(t), R is allocated to J
only if J is the job holding the resource(s) whose priority
ceiling is equal to Π(t), otherwise J is blocked
(Note that only one job may hold the resources whose priority
ceiling is equal to Π(t))
Note that unlike priority-inheritance protocol, the priority-ceiling
protocol can deny access to an available resource
23
Priority-Ceiling Protocol
At 1, Π(t) = Ω, J5 executes L(Black), continues executing
At 3, Π(t) = 2, J4 executes L(Shaded); because the ceiling of the
system Π(t) is higher than the current priority of J4, job J4 is blocked, J5
inherits J4’s priority and executes at priority 4
At 4, J3 preempts J5; at 5, J2 preempts J3. At 6, J2 requests Black and
is directly blocked by J5. Consequently, J5 inherits priority 2 and
executes until preempted by J1
24
Priority-Ceiling Protocol
Theorem 6
Assume a system of preemptable jobs with fixed assigned
priorities. Then
deadlock may never occur,
a job can be blocked for at most the duration of one critical
section.
25
These situations cannot occur with priority ceiling protocol:
26
Differences between the priority-inheritance and
priority-ceiling
Priority-inheritance is greedy, while priority ceiling is not
The priority-ceiling protocol may withhold access to a free
resource, i.e., a job can be blocked by a lower-priority job
which does not hold the requested resource – avoidance
blocking
The priority ceiling protocol forces a fixed order onto
resource accesses thus eliminating deadlock
27
Resources in Dynamic Priority Systems
The priority ceiling protocol assumes fixed and known priorities
In a dynamic priority system, the priorities of the periodic tasks
change over time, while the set of resources is required by
each task remains constant
As a consequence, the priority ceiling of each resource
changes over time
What happens if T1 uses resource X, but T2 does not?
Priority ceiling of X is 1 for 0 ≤ t ≤ 4, becomes 2 for
4 ≤ t ≤ 5, etc. even though the set of resources is required
by the tasks remains unchanged
28
Resources in Dynamic Priority Systems
If a system is job-level fixed priority, but task-level dynamic
priority, a priority ceiling protocol can still be applied
Each job in a task has a fixed priority once it is scheduled,
but may be scheduled at different priority to other jobs in
the task (e.g. EDF)
Update the priority ceilings of all resources each time a new
job is introduced; use until updated on next job release
Has been proven to prevent deadlocks and no job is ever
blocked for longer than the length of one critical section
But: very inefficient, since priority ceilings updated
frequently
May be better to use priority inheritance, accept longer
blocking
29
Schedulability Tests with Resources
How to adjust schedulability tests?
Add the blocking times to execution times of jobs; then run the
test as normal
The blocking time bi of a job Ji can be determined for all three
protocols:
non-preemptable CS ⇒ bi is bounded by the maximum
length of a critical section in lower priority jobs
priority-inheritance ⇒ bi is bounded by the total length of
the m longest critical sections where m is the number of
jobs that may block Ji
(For a more precise formulation see Theorem 2.)
priority-ceiling ⇒ bi is bounded by the maximum length of
a critical section
30