CSCE 990: Real-Time Systems
Resource Sharing
Steve Goddard
goddard@cse.unl.edu
http://www.cse.unl.edu/~goddard/Courses/RealTimeSystems
Jim Anderson
Real-Time Systems
Resource Sharing - 1
Resources & Resource Access Control
(Chapter 8 of Liu)
Until now, we have assumed that tasks are
independent.
We now remove this restriction.
We first consider how to adapt the analysis
discussed previously when tasks access shared
resources.
Later, in our discussion of distributed systems,
we will consider tasks that have precedence
constraints.
Jim Anderson
Real-Time Systems
Resource Sharing - 2
Shared Resources
We continue to consider single-processor
systems.
We add to the model a set of ρ serially reusable
resources R1, R2, …, Rρ, where there are vi
units of resource Ri.
» Examples of resources:
•
•
•
•
•
Jim Anderson
Binary semaphore, for which there is one unit.
Counting semaphore, for which there may be many units.
Reader/writer locks.
Printer.
Remote server.
Real-Time Systems
Resource Sharing - 3
Locks
A job that wants n units of resource R executes a
lock request, denoted L(R, n).
It unlocks the resource by executing a
corresponding unlock request, denoted U(R, n).
A matching lock/unlock pair is a critical section.
A critical section corresponding to n units of
resource R, with an execution cost of e, will be
denoted [R, n; e]. If n = 1, then this is simplified
to [R; e].
Jim Anderson
Real-Time Systems
Resource Sharing - 4
Locks (Continued)
Locks can be nested.
We will use notation like this:
» [R1; 14 [R4, 3; 9 [R5, 4; 3]]]
In our analysis, we will be mostly interested in
outermost critical sections.
Note: For simplicity, we only have one kind of
lock request.
» So, for example, we can’t actually distinguish
between reader locks and writer locks.
Jim Anderson
Real-Time Systems
Resource Sharing - 5
Conflicts
Two jobs have a resource conflict if some of
the resources they require are the same.
» Note that if we had reader/writer locks, then notion
of a “conflict” would be a little more complicated.
Two jobs contend for a resource when one job
requests a resource that the other job already
has.
The scheduler will always deny a lock request if
there are not enough free units of the resource to
satisfy the request.
Jim Anderson
Real-Time Systems
Resource Sharing - 6
Example
J1
J2
J3
0
2
4
6
8
10
12
14
16
18
= access of single-unit resource R
Jim Anderson
Resource Sharing - 7
Real-Time Systems
Timing Anomalies
When tasks share resources, there may be timing anomalies.
Example: Let us reduce J3’s critical section execution from 4 time
units to 2.5. Then J1 misses its deadline!
J1
J2
J3
0
Jim Anderson
2
4
6
8
10
Real-Time Systems
12
14
16
18
Resource Sharing - 8
Priority Inversions
When tasks share resources, there may be priority inversions.
Example:
priority inversion
J1
J2
J3
0
2
4
6
Jim Anderson
8
10
12
14
16
18
Resource Sharing - 9
Real-Time Systems
Deadlocks
When tasks share resources, deadlocks may be a problem.
Example: J1 accesses green, then red (nested). J3 accesses red, then
green (nested).
J1
J2
can’t lock green!
J3
0
2
4
6
8
10
12
14
16
18
What’s a very simple way to fix this problem?
Jim Anderson
Real-Time Systems
Resource Sharing - 10
Wait-for Graphs
We will specify blocking relationships using a wait-for graph.
Example:
J2
R,1
J3 has locked the single
unit of resource R and J2
is waiting to lock it.
J1
J3
Question: Can we use a wait-for graph to determine if there
is a deadlock?
Jim Anderson
Resource Sharing - 11
Real-Time Systems
Specifying Resource Requirements
Resource requirements will be specified like this:
J1
J2
2
4
R
1
Each job of T1 requires
2 units of R1 for at most
3 time units and one unit
of R2 for at most 1 time
unit.
4
J3
T1
(2; 3)
1
R1 5
T2
T3
[R2; 8 [R1, 4; 1][R1, 1; 5]]
R2 1
2
J1 requires the single-unit
resource R for 2 time units.
Jim Anderson
T4
Simple resource requirements are
shown on edges. Complicated ones
by the corresponding task.
Real-Time Systems
Resource Sharing - 12
Resource Access Control Protocols
We now consider several protocols for allocating
resources that control priority inversions and/or
deadlocks.
From now on, the term “critical section” is taken
to mean “outermost critical section” unless
specified otherwise.
Jim Anderson
Real-Time Systems
Resource Sharing - 13
Nonpreemptive Critical Section Protocol
The simplest protocol: just execute each critical
section nonpreemptively.
If tasks are indexed by priority (or relative deadline
in the case of EDF), then task Ti has a blocking
term equal to maxi+1 ≤ k ≤ n ck, where ck is the
execution cost of the longest critical section of Tk.
• We’ve talked before about how to incorporate such blocking
terms into scheduling analysis.
Advantage: Very simple.
Disadvantage: Ti’s blocking term may depend on
tasks that it doesn’t even have conflicts with.
Jim Anderson
Real-Time Systems
Resource Sharing - 14
The Priority Inheritance Protocol
(Sha, Rajkumar, Lehoczky)
Observation: In a system with lock-based resources, priority inversion
cannot be eliminated.
Thus, our only choice is to limit their duration. Consider again this
example:
J1
J2
J3
0
2
4
6
Jim Anderson
8
10
12
14
16
18
Resource Sharing - 15
Real-Time Systems
The Priority Inheritance Protocol
The problem here is not the low-priority job J3  it’s the medium
priority job J2!
We must find a way to prevent a medium-priority job like this from
lengthening the duration of a priority inversion.
J1
J2
J3
0
Jim Anderson
2
4
6
8
10
Real-Time Systems
12
14
16
18
Resource Sharing - 16
The Priority Inheritance Protocol
Priority Inheritance Protocol: When a low-priority job blocks a highpriority job, it inherits the high-priority job’s priority.
This prevents an untimely preemption by a medium-priority job.
J1
J2
executed at J1’s priority
J3
0
Jim Anderson
2
4
6
8
10
12
14
Real-Time Systems
16
18
Resource Sharing - 17
PIP Definition
Each job Jk has an assigned priority (e.g., RM priority) and a current priority πk(t).
1. Scheduling Rule: Ready jobs are scheduled on the processor preemptively in a
priority-driven manner according to their current priorities. At its release time t,
the current priority of every job is equal to its assigned priority. The job remains
at this priority except under the condition stated in rule 3.
2. Allocation Rule: When a job J requests a resource R at time t,
(a) if R is free, R is allocated to J until J releases it, and
(b) if R is not free, the request is denied and J is blocked.
3. Priority-Inheritance Rule: When the requesting job J becomes blocked, the job
Jl that blocks J inherits the current priority of J. The job Jl executes at its inherited
priority until it releases R (or until it inherits an even higher priority); the priority
of Jl returns to its priority πl(t′) at the time t′ when it acquires the resource R.
Jim Anderson
Real-Time Systems
Resource Sharing - 18
A More Complicated Example
(This is slightly different from the example in Figure 8-8 in the book.)
J1
J1
J1
J2
J2
J3
J4
J4
J1
J5 J 5 J 5
J2
J1
J1 J1
J1
This means this portion of the critical section executes at J2’s priority.
0
2
Jim Anderson
4
6
8
10
12
14
Real-Time Systems
16
18
20
Resource Sharing - 19
Properties of the PIP
We have two kinds of blocking with the PIP: direct
blocking and inheritance blocking.
• In the previous example, J2 is directly blocked by J5 over the
interval [6,9] and is inheritance blocked by J4 over the
interval [11,15].
Jobs can transitively block each other.
• At time 11.5, J5 blocks J4 and J4 blocks J1.
The PIP doesn’t prevent deadlock.
A jobs that requires v resources and conflicts with k lower
priority jobs can be blocked for min(v,k) times, each for
the duration of an outermost CS.
• It’s possible to do much better.
Jim Anderson
Real-Time Systems
Resource Sharing - 20
The Priority-Ceiling Protocol
(Sha, Rajkumar, Lehoczky)
Two key assumptions:
• The assigned priorities of all jobs are fixed (as before).
• The resources required by all jobs are know a priori before the
execution of any job begins.
Definition: The priority ceiling of any resource R is the
highest priority of all the jobs that require R, and is denoted
Π(R).
Definition: The current priority ceiling Π′(R) of the
system is equal to the highest priority ceiling of the
resources currently in use, or Ω if no resources are currently
in use (Ω is a priority lower than any real priority).
• Note: I’ve used ′ instead of ^ due to PowerPoint limitations.
Jim Anderson
Real-Time Systems
Resource Sharing - 21
PCP Definition
1. Scheduling Rule:
(a) At its release time t, the current priority π(t) of every job J equals its assigned priority.
The job remains at this priority except under the conditions of rule 3.
(b) Every ready job J is scheduled preemptively and in a priority-driven manner at its
current priority π(t).
2. Allocation Rule: Whenever a job J requests a resource R at time t, one of the following
two conditions occurs:
(a) R is held by another job. J’s request fails and J becomes blocked.
(b) R is free.
(i) If J’s priority π(t) is higher than the current priority ceiling Π′(t), R is allocated to J.
(ii) If J’s priority π(t) is not higher than the ceiling Π′(t), R is allocated to J only if J is
the job holding the resource(s) whose priority ceiling equals Π′(t); otherwise, J’s
request is denied and J becomes blocked.
3. Priority-Inheritance Rule: When J becomes blocked, the job Jl that blocks J inherits the
current priority π(t) of J. Jl executes at its inherited priority until it releases every resource
whose priority ceiling is ≥ π(t) (or until it inherits an even higher priority); at that time, the
priority of Jl returns to its priority π(t′) at the time t′ when it was granted the resources.
Jim Anderson
Real-Time Systems
Resource Sharing - 22
Example
(This is the PCP counterpart of our “complicated” PIP example.)
J1
J1
J1
J2
J2
J3
J4
J4
J5 J 5 J 5
0
J4
2
Jim Anderson
J2
4
6
J4 J4
J4
8
10
12
14
16
Real-Time Systems
18
20
Resource Sharing - 23
Properties of the PCP
The PCP is not greedy.
• For example, J4 in the example is prevented from locking
the green object, even though it is free.
We now have three kinds of blocking:
» Direct blocking (as before).
• For example, J5 directly blocks J2 at time 6.
» Priority-inheritance blocking (also as before).
• This doesn’t occur in our example.
» Priority-ceiling blocking (this is new).
• J4 suffers a priority-ceiling blocking at time 3.
Jim Anderson
Real-Time Systems
Resource Sharing - 24
Two Theorems
Theorem
Theorem8-1:
8-1: When
Whenthe
theresource
resourceaccesses
accessesof
ofaasystem
systemof
of
preemptive,
priority-driven
jobs
on
one
processor
are
controlled
preemptive, priority-driven jobs on one processor are controlled
by
bythe
thePCP,
PCP,deadlock
deadlockcan
cannever
neveroccur.
occur.
Theorem
Theorem8-2:
8-2:When
Whenthe
theresource
resourceaccesses
accessesof
ofaasystem
systemof
of
preemptive,
preemptive,priority-driven
priority-drivenjobs
jobson
onone
oneprocessor
processorare
arecontrolled
controlled
by
bythe
thePCP,
PCP,aajob
jobcan
canbe
beblocked
blockedfor
foratatmost
mostthe
theduration
durationof
ofone
one
critical
section.
critical section.
Jim Anderson
Resource Sharing - 25
Real-Time Systems
Deadlock Avoidance
With the PIP, deadlock could occur if nested critical sections are
invoked in an inconsistent order. Here’s an example we looked at earlier.
Example: J1 accesses green, then red (nested). J3 accesses red, then
green (nested).
J1
J2
can’t lock green!
J3
0
2
4
6
8
10
12
14
16
18
The PCP would prevent J1 from locking green. Why?
Jim Anderson
Real-Time Systems
Resource Sharing - 26
Blocking Term
Suppose J1 blocks when accessing the green critical section and later
blocks when accessing the red critical section.
blocks on green
J1
0
2
4
6
Jim Anderson
8
10
12
14
16
18
Resource Sharing - 27
Real-Time Systems
Blocking Term
For J1 block on green, some lower-priority job must have held the
lock on green when J1 began to execute.
blocks on green
J1
J2
0
Jim Anderson
2
4
6
8
10
Real-Time Systems
12
14
16
18
Resource Sharing - 28
Blocking Term
For J1 to later block on red, some lower-priority job must have held
the lock on red when J1 began executing.
blocks on green
blocks on red
J1
J2
J3
0
2
4
6
Jim Anderson
8
10
12
14
16
18
Resource Sharing - 29
Real-Time Systems
Blocking Term
Whichever way J2 and J3 are prioritized (here, J2 has priority over J3),
we have a contradiction. Why?
blocks on green
blocks on red
J1
J2
J3
0
Jim Anderson
2
4
6
8
10
Real-Time Systems
12
14
16
18
Resource Sharing - 30
Some Comments on the PCP
When computing blocking terms, it is important
to carefully consider all three kinds of blockings
(direct, inheritance, ceiling).
» See the book for an example where this is done
systematically (Figure 8-15).
With the PCP, we have to pay for extra two
context switches per blocking term.
» Such context switching costs can really add up in a
large system.
» This is the motivation for the Stack Resource Policy
(SRP), described next.
Jim Anderson
Real-Time Systems
Resource Sharing - 31
Stack-based Resource Sharing
So far, we have assumed that each task has its
own runtime stack.
In many systems, tasks can share a run-time
task.
This can lead to memory savings because there
is less fragmentation.
Jim Anderson
Real-Time Systems
Resource Sharing - 32
Stack-based Resource Sharing (Cont’d)
If tasks share a runtime stack, we clearly cannot
allow a schedule like the following. (Why?)
J1
J2
We must delay the execution of each job until
we are sure all the resources it needs are
available.
Jim Anderson
Real-Time Systems
Resource Sharing - 33
Stack Resource Policy
(Baker)
0. Update of the Current Ceiling: Whenever all the resources are free,
the ceiling of the system is Ω. The ceiling Π′(t) is updated each
time a resource is allocated or freed.
1. Scheduling Rule: After a job is released, it is blocked from starting
executing until its assigned priority is higher than the current
ceiling Π′(t) of the system. At all times, jobs that are not blocked
are scheduled on the processor in priority-driven, preemptive manner
according to their assigned priorities.
2. Allocation Rule: Whenever a job requests a resource, it is allocated
the resource.
Note: Can be implemented using a single runtime stack, but this isn’t
required.
Jim Anderson
Real-Time Systems
Resource Sharing - 34
Example
(This is the SRP counterpart of our “complicated” example.)
J1
J2
J3
Notice how J4 incurs its blocking term “up
front,” before it actually starts to execute.
J4
J5
0
2
Jim Anderson
4
6
8
10
12
14
Real-Time Systems
16
18
20
Resource Sharing - 35
Properties of the SRP
No job is ever blocked once its execution
begins.
» Thus, there can never be any deadlock.
The blocking term calculation is the same as
with the PCP.
» Convince yourself of this!
» One difference, though: With the SRP, a job is
blocked only before it begins execution, so extra
context switches due to blockings are avoided.
Jim Anderson
Real-Time Systems
Resource Sharing - 36
Scheduling, Revisited
We have already talked about how to incorporate blocking terms into
scheduling conditions.
For example, with TDA and generalized TDA, we changed our timedemand function by adding a blocking term. For TDA, we got this:
w i (t) = e i + b i +
i −1
k =1
t
⋅ ek
pk
for 0 < t ≤ min(Di , p i )
For EDF-scheduled systems, we stated the following utilization-based
condition:
n
ek
bi
+
≤1
min(Di , p i )
k =1 min(D k , p k )
Jim Anderson
Real-Time Systems
Resource Sharing - 37
A Closer Look at Dynamic-Priority
Systems
It turns out that this EDF condition is not very tight.
We now cover a paper by Jeffay that presents a
much tighter condition.
» Although it may not seem like it on first reading, Jeffay’s
paper basically reinvents the SRP, but for dynamicpriority systems.
» However, the scheduling analysis for dynamic-priority
systems given by Jeffay is much better than that found
elsewhere.
Jim Anderson
Real-Time Systems
Resource Sharing - 38
Scheduling Sporadic Tasks with Shared
Resources
(Jeffay)
In the model of this paper, each task Ti is
partitioned into ni distinct phases.
» In each phase, either no resource is required or
exactly one resource is required.
» If resource Rk is required by Ti’s jth phase, then we
denote this by rij = k, where 1 ≤ k ≤ m.
» If no resource is required, then rij = 0.
Jim Anderson
Real-Time Systems
Resource Sharing - 39
Single-Phase Systems
In a single-phase system, each task is either a critical section that
accesses some resource, or a non-critical section that accesses
no resource.
Notation: Each task Ti will be denoted by (si, (ci, Ci, ri), pi) where:
• si is its release time;
• ci is its minimum execution cost;
• Ci is its maximum execution cost;
• ri indicates which (if any) resource is accessed;
• pi is its period.
Definition: We let Pi denote the period of the “shortest” task that
requires resource Ri, i.e., Pi = min1 ≤ j ≤ n (pj | rj = i).
Jim Anderson
Real-Time Systems
Resource Sharing - 40
Necessary Scheduling Condition
Theorem
Theorem3.2:
3.2:Let
LetTT=={T
{T11,,TT22,,…,
…,TTnn}}be
beaasystem
systemof
ofsingle-phase,
single-phase,
sporadic
tasks
with
relative
deadlines
equal
to
their
periods
sporadic tasks with relative deadlines equal to their periodssuch
suchthat
that
the
tasks
in
T
are
indexed
in
non-decreasing
order
by
period
the tasks in T are indexed in non-decreasing order by period(i.e.,
(i.e.,
ififii<<j,j,then
If T is schedulable on a single processor, then:
thenppi i≤≤ppj).
j). If T is schedulable on a single processor, then:
n
1)
i =1
Ci
≤1
pi
2) ∀i : 1 ≤ i ≤ n ∧ ri ≠ 0 :: ∀L : Pri < L < p i :: L ≥ Ci +
i -1
j=1
L −1
⋅Cj
pj
Compare this to the feasibility condition we had for nonpreemptive
EDF, which is repeated on the following slide.
Jim Anderson
Resource Sharing - 41
Real-Time Systems
Non-preemptive EDF, Revisited
Theorem
Theorem::Let
LetTT=={T
{T11,,TT22,,…,
…,TTnn}}be
beaasystem
systemof
ofindependent,
independent,
periodic
tasks
with
relative
deadlines
equal
to
their
periodic tasks with relative deadlines equal to theirperiods
periodssuch
suchthat
that
the
tasks
in
T
are
indexed
in
non-decreasing
order
by
period
(i.e.,
the tasks in T are indexed in non-decreasing order by period (i.e.,
ififii<<j,j,then
T can be scheduled by the non-preemptive EDF
thenppi i≤≤ppj).
j). T can be scheduled by the non-preemptive EDF
algorithm
if:
algorithm if:
n
ei
≤1
1)
i =1 p i
2) ∀i : 1 ≤ i ≤ n :: ∀L : p1 < L < pi :: L ≥ ei +
i -1
j=1
L −1
⋅ej
pj
Remember, we showed this condition is also necessary for sporadic
tasks.
Jim Anderson
Real-Time Systems
Resource Sharing - 42
Proof Sketch of Theorem 3.2
Given our previous discussion of nonpreemptive EDF, Theorem 3.2
should be pretty obvious.
Clearly, if T is schedulable, total utilization must be at most one, i.e.,
condition (1) must hold.
Condition (2) accounts for the worst-case blocking that can be
experienced by each task Ti.
Remember, with nonpreemptive EDF, the “worst-case” pattern of
job releases occurs when a job of some Ti begins executing
(non-preemptively!) one time unit before some tasks with smaller
periods begin releasing some jobs.
Jim Anderson
Real-Time Systems
Resource Sharing - 43
Proof Sketch (Continued)
Here’s an illustration:
T1
T2
T3
Ti
Moreover, with sporadic tasks, such releases are always possible, and
thus if T is schedulable, then it is necessary to ensure no deadline is
missed in the face of job releases like this.
In a single-phase system, we have the same kind of necessary condition,
but now a task may only be blocked by a task that accesses a common
resource.
Jim Anderson
Real-Time Systems
Resource Sharing - 44
EDF-DDM
Our goal now is to define a scheduling algorithm for which
the conditions of Theorem 3.2 are necessary.
Since EDF is optimal in the absence of resources, it makes
sense to look at some variant of EDF.
Remember with the PIP, PCP, and SRP, the idea is to raise a
lower-priority job’s priority when a blocking occurs.
With EDF, raising a priority means temporarily “shrinking”
the job’s deadline.
The resulting scheme is called EDF with dynamic
deadline modification.
Jim Anderson
Real-Time Systems
Resource Sharing - 45
Example
Here’s what can happen without dynamic deadline modification:
T1
T2
T3
0
1
2…
Here’s the corresponding schedule with dynamic deadline modification:
T1
Notice that T2
does not
preempt T1 at
time 1.
T2
T3
0
Jim Anderson
1
2…
Real-Time Systems
Resource Sharing - 46
EDF/DDM Definition
Let tr be the time when job J of task Ti is
released, and let ts be the time job J starts to
execute.
In the interval [tr, ts), J’s deadline is tr + pi, just
like with EDF.
» This is called J’s initial deadline.
At time ts, J’s deadline is changed to
min(tr + pi, (ts + 1) + Pri).
» This is called J’s contending deadline.
Jim Anderson
Real-Time Systems
Resource Sharing - 47
Sufficient Condition for EDF/DDM
Theorem
Theorem3.4:
3.4:Let
LetTT=={T
{T11,,TT22,,…,
…,TTnn}}be
beaasystem
systemof
ofsingle-phase,
single-phase,
sporadic
tasks
with
relative
deadlines
equal
to
their
periods
sporadic tasks with relative deadlines equal to their periodssuch
suchthat
that
the
tasks
in
T
are
indexed
in
non-decreasing
order
by
period
(i.e.,
the tasks in T are indexed in non-decreasing order by period (i.e.,
ififii<<j,j,then
The EDF/DDM discipline will succeed in
thenppi i≤≤ppj).
j). The EDF/DDM discipline will succeed in
scheduling
T
if
conditions
scheduling T if conditions(1)
(1)and
and(2)
(2)from
fromTheorem
Theorem3.2
3.2hold.
hold.
Thus, by Theorem 3.2, (1) and (2) are feasibility conditions.
Not surprisingly, the proof of Theorem 3.4 is very similar to the
corresponding proof we did for nonpreemptive EDF systems.
Jim Anderson
Real-Time Systems
Resource Sharing - 48
Proof of Theorem 3.4
Suppose conditions (1) and (2) hold for T but a deadline is missed.
Let td be the earliest point in time at which a deadline is missed.
There are two cases.
Case 1: No job with an initial deadline after time td is scheduled prior
to time td. The analysis is just like with preemptive EDF.
As before, let t-1 be the last “idle instant”. (This is denoted t0 in the
paper, but I’ve used t-1 to be consistent with previous proofs.)
Because a deadline is missed at td, demand over [t-1, td] exceeds
td − t-1. In addition, this demand is at most j=1,..,n (td − t-1)/pj ⋅Cj.
Thus, we have td − t-1 <
j=1,..,n
(td − t-1)/pj ⋅Cj ≤
j=1,..,n
[(td − t-1)/pj]⋅Cj.
This implies utilization exceeds one, which contradicts condition (1).
Jim Anderson
Resource Sharing - 49
Real-Time Systems
Proof (Continued)
Case 2: Some job with an initial deadline after time td is scheduled
prior to time td.
Let Ti be the task with the last job with an initial deadline after td that is
scheduled prior to td. Then, we have the following:
Ti
Time
ti
td
Let us bound the processor demand in [ti, td] … (This is where things
start to get a little different from the nonpreemptive EDF proof.)
Jim Anderson
Real-Time Systems
Resource Sharing - 50
Proof (Continued)
Case 2a: Ti’s contending deadline is less than or equal to td.
This means Ti must be a resource requesting task. We have the
following:
contending
initial
Ti
Time
ti
td
The proof for this subcase is very much like Case 2 in the
nonpreemptive EDF proof (we get a contradiction of condition (2)).
Jim Anderson
Real-Time Systems
Resource Sharing - 51
Proof (Continued)
Observe the following:
» Other than task Ti, no task with a period greater than
or equal to td − ti executes in the interval [ti, td].
• Such a task would contradict our choice of Ti.
» Other than Ti, no task that executes in [ti, td] could
have been invoked at time ti.
» The processor is fully utilized in [ti, td].
Jim Anderson
Real-Time Systems
Resource Sharing - 52
Proof (Continued)
From these facts, we conclude that demand over [ti, td] is less than or
equal to
Ci +
i -1
j=1
t d − (t i + 1)
⋅ C j.
pj
Let L = td − ti. We have pi > L > Pri. (Why?) Also,
L < Ci +
i -1
j=1
L −1
⋅ C j.
pj
This contradicts condition (2).
Jim Anderson
Resource Sharing - 53
Real-Time Systems
Proof (Continued)
Case 2b: Ti’s contending deadline is greater than td.
This means either Ti doesn’t request any resource or (ti + 1) + Pri > td.
We have the following:
contending
Ti
Time
ti
td
Ti is preemptable by any job whose period lies with [ti, td]. (Why?)
Jim Anderson
Real-Time Systems
Resource Sharing - 54
Proof (Continued)
Let t-1 > ti be the later of the end of the last idle period in [ti, td] or the
time Ti last stops executing prior to td.
All invocations of tasks occurring prior to t-1 with deadlines less than
or equal to td must have completed executing by t-1. (Why?)
contending
Ti
Time
ti
t-1
td
As in Case 1, we can show that demand over [t-1, td] exceeds
td − t-1, which implies that condition (1) is violated.
Jim Anderson
Resource Sharing - 55
Real-Time Systems
Multi-Phase Systems
Notation: In a multi-phase system, each task Ti is denoted by
(si, (cij, Cij, rij), pi), 1 ≤ i ≤ n, 1 ≤ j ≤ ni, where:
• si is its release time;
• nj is the number of phases in each job of Ti;
• cij is the minimum execution cost of the jth phase;
• Cij is the maximum execution cost of the jth phase;
• rij indicates which (if any) resource is accessed in the jth phase;
• pi is its period.
Definition: We let Prik = min1 ≤ j ≤ n (pj | rjl = rik for some l in the range
1 ≤ l ≤ nj).
Definition: The execution cost of Ti is Ei =
Jim Anderson
Real-Time Systems
k = 1,…,ni
Cik.
Resource Sharing - 56
Necessary Scheduling Condition
Theorem
Theorem4.1:
4.1:Let
LetTT=={T
{T11,,TT22,,…,
…,TTnn}}be
beaasystem
systemof
ofmulti-phase,
multi-phase,
sporadic
tasks
with
relative
deadlines
equal
to
their
periods
sporadic tasks with relative deadlines equal to their periodssuch
suchthat
that
the
tasks
in
T
are
indexed
in
non-decreasing
order
by
period
the tasks in T are indexed in non-decreasing order by period(i.e.,
(i.e.,
ififii<<j,j,then
If T is schedulable on a single processor, then:
thenppi i≤≤ppj).
j). If T is schedulable on a single processor, then:
n
1)
i =1
Ei
≤1
pi
2) (∀i, k : 1 ≤ i ≤ n ∧ 1 ≤ k ≤ n i ∧ rik ≠ 0 ::
∀L : Prik < L < p i − Sik :: L ≥ Cik +
where Sik =
0
k −1
c
j=1 ij
i -1
j=1
L −1
⋅Ej
pj
if k = 1
if 1 < k ≤ n i
Ugh!
Jim Anderson
Real-Time Systems
Resource Sharing - 57
EDF/DDM for Multi-phase Systems
Let tr be the time when job J of task Ti is released, and let tsk
be the time job J’s kth phase starts to execute.
In the interval [tr, ts), J’s deadline is tr + pi, just like with
EDF.
At time tsk, J’s deadline is changed to min(tr + pi, (tsk + 1) +
Prik).
When one of J’s phases completes, its deadline immediately
reverts to tr + pi.
Note that this algorithm prevents a job from beginning
execution until all the resources it requires are available,
i.e., this is just a dynamic-priority SRP.
Jim Anderson
Real-Time Systems
Resource Sharing - 58
Sufficient Condition for EDF/DDM
Theorem
Theorem4.3:
4.3:Let
LetTT=={T
{T11,,TT22,,…,
…,TTnn}}be
beaasystem
systemof
ofmulti-phase,
multi-phase,
sporadic
tasks
with
relative
deadlines
equal
to
their
periods
sporadic tasks with relative deadlines equal to their periodssuch
suchthat
that
the
tasks
in
T
are
indexed
in
non-decreasing
order
by
period
the tasks in T are indexed in non-decreasing order by period(i.e.,
(i.e.,
ififii<<j,j,then
The EDF/DDM discipline will succeed in
thenppi i≤≤ppj).
j). The EDF/DDM discipline will succeed in
scheduling
schedulingTTififconditions
conditions(1)
(1)and
and(2)
(2)from
fromTheorem
Theorem4.1
4.1hold.
hold.
Thus, by Theorem 4.1, (1) and (2) are feasibility conditions for
multi-phase, sporadic task systems.
We will not cover the proofs of Theorems 4.1 and 4.3 in class, but
you should read through them in the paper.
Jim Anderson
Real-Time Systems
Resource Sharing - 59
An Alternative to Critical Sections
Critical sections are often used to implement
software shared objects.
» Example: producer/consumer buffer.
Such objects actually can be implemented without
using critical sections or related mechanisms.
Such shared-object algorithms are called
nonblocking algorithms.
Bottom Line: We can avoid priority inversions
altogether when implementing software shared
objects.
Jim Anderson
Real-Time Systems
Resource Sharing - 60
Nonblocking Algorithms
Two variants:
» Lock-Free:
• Perform operations “optimistically”.
• Retry operations that are interfered with.
» Wait-Free:
• No waiting of any kind:
– No busy-waiting.
– No blocking synchronization constructs.
– No unbounded retries.
Recent research at UNC has shown how to account for
lock-free and wait-free overheads in scheduling analysis.
First, some background …
Jim Anderson
Resource Sharing - 61
Real-Time Systems
Lock-Free Example
type
type Qtype
Qtype==record
recordv:v:valtype;
valtype;next:
next: pointer
pointertotoQtype
Qtypeend
end
shared
sharedvar
var Tail:
Tail: pointer
pointerto
toQtype;
Qtype;
local
localvar
var old,
old,new:
new:pointer
pointerto
toQtype
Qtype
procedure
procedureEnqueue
Enqueue(input:
(input:valtype)
valtype)
new
new:=
:=(input,
(input, NIL);
NIL);
repeat
repeat old
old:=
:=Tail
Tail
until
CAS2(&Tail,
until CAS2(&Tail,&(old->next),
&(old->next),old,
old,NIL,
NIL,new,
new,new)
new)
old
new
old
Tail
Tail
Jim Anderson
new
Real-Time Systems
Resource Sharing - 62
Wait-Free Algorithms
(Herlihy’s Helping Scheme)
pointer to
shared
object
“current”
copy
Algorithm:
process p’s
copy
“announce”
“announce”operation;
operation;
retry
retryuntil
untildone:
done:
create
createlocal
localcopy
copyofofthe
theobject;
object;
apply
applyall
allannounced
announcedoperations
operations
on
onlocal
localcopy;
copy;
attempt
attemptto
tomake
makelocal
localcopy
copythe
the
“current”
“current”copy
copyusing
usingaa
strong
strongsynchronization
synchronization
primitive
primitive
process q’s
copy
process r’s
copy
“announce” array
Can only retry once!
Disadvantage: Copying overhead.
Jim Anderson
Real-Time Systems
Resource Sharing - 63
Using Wait-Free Algorithms in Realtime Systems
On uniprocesors, helping-based algorithms are
not very attractive.
» Only high-priority tasks help lower-priority tasks.
– Similar to priority inversion.
» Such algorithms can have high overhead due to
copying and having to use costly synchronization
primitives.
– Some wait-free algorithms avoid these problems and are useful.
– Example: “Collision avoiding” read/write buffers.
On the other hand, on multiprocessors, wait-free
algorithms may be the best choice.
Jim Anderson
Real-Time Systems
Resource Sharing - 64
Using Lock-Free Objects on Real-time
Uniprocessors
(Anderson, Ramamurthy, Jeffay)
Advantages of Lock-free Objects:
» No priority inversions.
» Lower overhead than helping-based wait-free
objects.
» Overhead is charged to low-priority tasks.
But:
» Access times are potentially unbounded.
Jim Anderson
Real-Time Systems
Resource Sharing - 65
Scheduling with Lock-Free Objects
On a uniprocessor, lock-free retries really aren’t unbounded.
AAtask
taskfails
failsto
toupdate
updateaashared
sharedobject
objectonly
onlyifif
preempted
preemptedduring
duringits
itsobject
objectcall.
call.
High
Low
Failed retry-loop
Successful retry-loop
Can compute a bound on retries by counting preemptions.
Jim Anderson
Real-Time Systems
Resource Sharing - 66
RM Sufficient Condition
Assume rate-monotonic priority assignment.
Sufficient Scheduling Condition:
∀i :: ∃t : 0 < t ≤ p i ::
i
j=1
t
ej +
pj
i −1
j=1
t
s≤t
pj
In this condition, s is the time to update a lock-free object (one retry
loop iteration).
We are assuming at this point that all retry loops have the same cost.
Jim Anderson
Resource Sharing - 67
Real-Time Systems
Proof of RM Condition
The proof strategy should be very familiar to you by now.
To Prove: If a task set is not schedulable, then the
sufficient condition does not hold, i.e.,
∃i :: ∀t : 0 < t ≤ p i ::
Jim Anderson
i
j=1
t
ej +
pj
Real-Time Systems
i −1
j=1
t
s>t
pj
Resource Sharing - 68
Setting Up the Proof…
Let the kth job of Ti be the first to miss its deadline.
Let t-1 be the latest “idle instant” before ri,k+1.
s
High
Med
Ti
t-1
Failed retry-loop
Jim Anderson
ri,k+1
ri,k
Successful retry-loop
Real-Time Systems
Resource Sharing - 69
Intuition
If a task set is not schedulable, then at all instants t in (t-1,ri,k+1],
the
thedemand
demandplaced
placedon
onthe
theprocessor
processorby
byTTi i
and
higher-priority
tasks
in
[t
,t)
is
greater
and higher-priority tasks in [t-1-1,t) is greaterthan
than
the
available
processor
time
in
[t
,t).
the available processor time in [t-1-1,t).
Suppose not:
• Case t ∈ (t-1,ri,k]: Contradicts choice of t-1.
• Case t ∈ (ri,k,ri,k+1]: Ti’s deadline at ri,k+1 is not missed.
Jim Anderson
Real-Time Systems
Resource Sharing - 70
Finishing the Proof ...
For any t in (t-1,ri,k+1], the following holds.
available processor time in [t-1,t)
< demand due to Ti and higher-priority jobs in [t-1,t)
= demand due to job releases of Ti and higher-priority tasks
+ demand due to failed loop tries in Ti and higher-priority tasks
≤
(number of jobs of Tj released in [t-1,t) )·ej
+ j=1…,i-1(number of preemptions Tj can cause in Ti and
higher-priority tasks) · (cost of failed loop try)
j=1…,i
Jim Anderson
Resource Sharing - 71
Real-Time Systems
… Finishing the Proof
Hence, for any t in (t-1,ri,k+1],
t − t −1 <
i
j=1
t − t −1
ej +
pj
i −1
j=1
t − t −1
s.
pj
Replacing t − t-1 by t´ in (0, ri,k+1 − t-1],
t′ <
i
j=1
Jim Anderson
t′
ej +
pj
i −1
j=1
Real-Time Systems
t′
s.
pj
Resource Sharing - 72
EDF Sufficient Condition
Assume earliest-deadline-first priority assignment.
Sufficient Condition:
N
ej + s
j=1
pj
≤1
As before … To Prove: If a task set T is not schedulable, then
Jim Anderson
N
ej + s
j=1
pj
>1
Resource Sharing - 73
Real-Time Systems
Setting Up the Proof...
Same set-up as before…
s
Ti
t-1
ri,k
Failed retry-loop
Jim Anderson
ri,k+1
Successful retry-loop
Real-Time Systems
Resource Sharing - 74
Intuition
IfIfaatask
taskset
setisisnot
notschedulable,
schedulable,then
thenthe
thedemand
demand
placed
on
the
processor
in
[t
,r
)
by
jobs
placed on the processor in [t-1-1,ri,k+1
i,k+1) by jobs
with
is greater than
withdeadlines
deadlinesatator
orbefore
beforerri,k+1
i,k+1 is greater than
the
].
theavailable
availableprocessor
processortime
timein
in[t[t-1-1,r,ri,k+1
i,k+1].
Jim Anderson
Real-Time Systems
Resource Sharing - 75
Finishing the Proof ...
available processor time in [t-1,ri,k+1]
< demand due to jobs with deadlines ≤ ri,k+1
= demand due to releases of those jobs
+ demand due to failed loop tries in those jobs
≤
[number of jobs of Tj with deadlines at or before
ri,k+1 released in [t-1,ri,k+1)] ·ej
+ j=1,…,N (number of preemptions Tj can cause in such
jobs) · (cost of failed loop try)
Jim Anderson
j=1,…,N
Real-Time Systems
Resource Sharing - 76
… Finishing the Proof
Hence,
ri, k +1 − t −1 <
N
ri, k +1 − t −1
j=1
pj
ej +
N
ri, k +1 − t −1
j=1
pj
s,
which implies,
ri,k +1 − t −1 <
N
ri,k +1 − t −1
j=1
pj
ej +
N
ri,k +1 − t −1
j=1
pj
s.
Canceling ri,k+1 – t-1 yields
1<
Jim Anderson
N
ej
j=1
pj
+
N
j=1
Real-Time Systems
s
.
pj
Resource Sharing - 77
Comparison of Lock-Free & Lock-Based
It can be shown analytically that lock-free wins
over lock-based if:
» (lock-free access cost) ≤ (lock-based access cost)/2.
• For many objects, this will be the case, because with a lockbased implementation, you get one object access for the
price of many (due to all the kernel objects that have to be
accessed).
Breakdown utilization experiments involving
randomly-generated task sets show that lock-free
is likely to win if:
» (lock-free access cost) ≤ (lock-based access cost).
Jim Anderson
Real-Time Systems
Resource Sharing - 78
Better Scheduling Conditions
Previous conditions perform poorly when retry
loop costs vary widely.
Also, they over-count interferences (not every
preemption causes an interference).
Question: How to incorporate different retry
loop costs?
Answer: Use linear programming.
» Can apply linear programming to both RM and EDF
(and also DM).
» We only consider RM here.
Jim Anderson
Real-Time Systems
Resource Sharing - 79
Linear-Programming RM Condition
(Anderson and Ramamurthy)
Definition:
E i (t) ≡
i
w(j) j−1
j=1 v =1 l =1
m lj,v (t)slj,v
w(j) - Number of phases of Tj.
mlj,v(t) - Number of interferences in Tj’s vth phase due to Tl in an
interval of length t.
j,v
sl - Cost of one such interference.
Approach: View Ei(t) as a linear expression, where mlj,v(t) are
the variables.
Maximize Ei(t) subject to some constraints.
Jim Anderson
Real-Time Systems
Resource Sharing - 80
LP RM Condition (Continued)
Example Constraints (the easy ones):
∀i, j : j < i ::
w(i)
v =1
∀i ::
i
w(j) j−1
j=1 v =1 l =1
m i,jv (t) ≤
m lj, v (t) ≤
i −1
j=1
t +1
pj
t +1
pj
Let Ei´(t) be an upper bound on Ei(t) obtained by linear programming.
RM Condition:
Jim Anderson
∃t : 0 < t ≤ p i ::
i
j=1
Real-Time Systems
t
e j + E′i (t − 1) ≤ t
pj
Resource Sharing - 81