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]
185
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
186
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 187
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
188
Example
� At 9, J3 executes U(R) and both J1 and J2 are unblocked. J1 has higher
priority than J2 and executes
� At 11, J1 executes U(R) and continues executing
� At 12, J1 completes, J2 has higher priority than J3 and has the resource
R, thus executes
� At 16, J2 executes U(R) and continues executing
� At 17, J2 completes, J3 executes until completion at 18
188
Priority Inversion
Definition 27
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
189
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)
190
Deadlock
Definition 28 (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)
See your operating systems course for more information ....
191
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
192
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! 193
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
� ....
Terminology:
� A job Jh is blocked by a job Jk when
� the priority of Jk is lower than the priority of Jh and
� Jk holds a resource R and
� Jh executes L(R).
In such situation we sometimes say that Jh is blocked by
the corresponding critical section of Jk .
194
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 29
Jobs J1, J2, J3 with release times 2, 5, 0, resp., and with
execution times 4, 5, 7, resp.
195
Non-preemptive Critical Sections – Features
� no deadlock as no job holding a resource is ever preempted
� no priority inversion:
� A job Jh can be blocked (by a lower priority job) only at
release time.
(Indeed, if Jh is not blocked at the release time rh, it means that no
lower priority job holds any resource at rh. However, no lower
priority job can be executed before completion of Jh, and thus no
lower priority job may block Jh.)
� If Jh is blocked at release time, then once the blocking
critical section completes, no lower priority job can block Jh.
� It follows that 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
196
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)
197
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;
� Jk executes at its inherited priority until it releases R;
at that time, the priority of Jk is set to the highest priority of
all jobs still blocked by Jk after releasing R.
(the resulting priority 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
(Note that J is only denied R if the resource is held by another job.)
198
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
199
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
200
Priority-Inheritance Example
� At 8, J1 executes L(Shaded) and is blocked by J4. Thus J4 inherits the
priority 1 of J1 and executes
� At 9, J4 executes L(Black) and is blocked by J5. Thus J5 inherits the
current priority 1 of J4 and executes
200
Priority-Inheritance Example
� At 11, J5 executes U(Black), its priority returns to 5 (the priority before
locking Black). Now J4 has the highest priority (1) and executes
the Black critical section.
Later, when J4 executes U(Black), the priority of J4 remains 1 (since
Shaded blocks J1), and J4 also finishes the Shaded critical section
(at 13).
200
Priority-Inheritance Example
� At 13, J4 executes U(Shaded), its priority returns to 4. J1 has now the
highest priority and executes
� At 15, J1 completes, J2 is granted Black and has the highest priority and
executes
� At 17, J2 completes, afterwards J3, J4, J5 complete.
200
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
201
Priority-Inheritance – Blocking Time (Optional)
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,
i.e., which correspond to resources that are (potentially) used by jobs
with priorities equal or higher than 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 30
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}.
The theorem is a direct consequence of the next lemma.
202
Lemma 31
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. 203
Priority-Inheritance – The Worst Case
J1 is blocked for the total duration of all critical sections in all lower
priority jobs.
204
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
205
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;
� Jk executes at its inherited priority until it releases R;
at that time, the priority of Jk is set to the highest priority of
all jobs still blocked by Jk after releasing R.
(which may still be an inherited priority)
206
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 strictly 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.
207
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
208
Priority-Ceiling Protocol
� At 8, J1 executes L(Shaded), its priority is higher than Π(t) = 2, its
request is granted and J1 executes; at 9, J1 executes U(Shaded) and at
10 completes
� At 11, J5 releases Black and its priority drops to 5; J2 becomes
unblocked, is allocated Black and executes
208
Priority-Ceiling Protocol
� At 14, J2 and J3 complete, J4 is granted Shaded (because its priority is
higher than Π(t) = Ω) and executes
� At 16, J4 executes L(Black) which is free, the priority of J4 is not higher
than Π(16) = 1 but J4 is the job holding the resource whose priority
ceiling is equal to Π(16). Thus J4 gets Black, continues to execute;
the rest is clear
208
Priority-Ceiling Protocol
Theorem 32
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.
209
These situations cannot occur with priority ceiling protocol:
210
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 prevented from execution 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
211
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
212
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
213
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
214
Mars Pathfinder vs Priority Inversion
� Mars Pathfinder = a US spacecraft that landed
on Mars in July 4th, 1997.
� Consisted of a lander and a lightweight
wheeled robotic Mars rover called Sojourner
� What Happened:
� Few days in to the mission, not long after Pathfinder started
gathering meteorological data, it began experiencing total
system resets, each resulting in losses of data.
� Apparently a software problem caused these resets.
� The system:
� Pathfinder used the well-known real-time embedded
systems kernel VxWorks by Wind River.
� VxWorks uses preemptive priority-based scheduling, in this
case a deadline monotonic algorithm.
� Pathfinder contained an "information bus" (a shared
memory) used for communication, synchronized by locks.
215
Mars Pathfinder – The Problem
� Problematic tasks:
� A bus management task ran frequently with high priority to
move data in/out of the bus. If the bus has been locked,
then this thread itself had to wait.
� A meteorological data gathering task ran as an infrequent,
low priority thread, and used the bus to publish its data.
� The bus was also used by a communication task that ran
with medium priority.
� Occasionally the communication task (medium priority) was
invoked at the precise time when the bus management task
(high priority) was blocked by the meteorological data gathering
task (low priority) – priority inversion!
� The bus management task was blocked for considerable amount
of time by the communication task, which caused a watchdog
timer to go off, notice that the bus management task has not
been executed for some time, which typically means that
something had gone drastically wrong, and initiate a total system
reset.
216
Mars Pathfinder – Solution
� JPL (Jet Propulsion Laboratory) engineers spent hours and
hours running the system on a spacecraft replica.
� Early in the morning, after all but one engineer had gone home,
the engineer finally reproduced a system reset on the replica.
Solution: Turn the priority inheritance on!
This was done online using a C language interpreter which allowed to
execute C functions on-the-fly.
A short code changed a mutex initialization parameter from FALSE to
TRUE.
217