1. technology and computing
2. operating systems

Real-Time Systems – Dependencies
4.1 Motivation
Real-Time Systems
Summer term 2015
Introduction
▸
Assumptions till now: no interaction, no dependencies á not realistic
▸
Kinds of interaction (cf. Course “Operating Systems”, Chapter 5)
Real-Time Systems
▸
4. Chapter
▸
Dependencies
▸
▸
Prof. Matthias Werner
▸
Operating Systems Group
Communication
Cooperation
Coordination
Critical for real-time systems: coordination á order, synchronization
We focus on mutual exclusion due to
▸
▸
critical sections
limited number of resources
summer term 2015 ⋅ M. Werner
Real-Time Systems – Dependencies
4.2 Access Control
2 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Recap: Critical Section
Model
Critical Section
A critical section is a sequence of commands where a mixed execution of two (or
more) execution streams may lead to an error (inconsistency).
▸
One can view a critical section as a special kind of resource
▸
// . . .
index = index +1;☇
buffer [ index ] = 42;
// . . .
// . . .
index = index +1;
buffer [ index ] = 23;
// . . .
▸
Thus, the different cases can be summarized á resource reservation
▸
Language devices
▸
▸
actual order of commands:
// ...
index = index+1;
index = index+1;
buffer[index] = 23;
// ...
buffer[index] = 42;
summer term 2015 ⋅ M. Werner
▸
result:
3 / 49
▸
▸
one buffer value is undefined
▸
The value 42 is “lost”
osg.informatik.tu-chemnitz.de
There is one instance only
lock, mutex
semaphore
monitor
⋮
summer term 2015 ⋅ M. Werner
4 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Real-Time Systems – Dependencies
4.2 Access Control
Notations
Blocking
In case of exclusive access, a low-priority task may block a high-priority task
Invalidates standard assumptions
á Statements about feasibility are void, too
▸
▸
We use the following notations:
Ji : job
πi : priority of Ji
Note:
Ri : resource with exclusive access
“Normal” preemption does not count to blocking.
J ▹R: J requests R (event)
J ◇R: J holds R (state)
Known maximal blocking times allows for TDA with adopted time demand
function
▸
J ▿R: J releases R (event)
X êJ: X blocks J
êJ: J is blocked
R êJ: resource R blocks J
Ji êJk : job Ji blocks Jk
i−1
wi (t) = ei + tb,i + ∑ ⌈
k=1
t
⌉ ⋅ ek
Pk
tb,i ∶ Maximum time for which task Ti is blocked
summer term 2015 ⋅ M. Werner
5 / 49
summer term 2015 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Priority Inversion
▸
6 / 49
Priority Inversion (cont.)
Consider the following example:
J1
J2
▸
Priority inversion: a medium-priority job blocks indirectly by means of a
low-priority job a job of high priority
▸
The blocking job itself does not need any resource
...
J3
0
2
4
6
8
10
12
14
16
18
t
Note
t = 1: J3 accesses R, that is later required also by J1
Sometimes the literature uses the term priority inversion to denote “normal” blocking.
t = 2: J1 becomes ready and interrupts J3 (preemption)
Then, the phenomenon considered here is called unbounded priority inversion.
t = 3: J1 requires R á blocked by J3 á J3 continues to run
t = 5: J2 runs and preempts J3 and thus also J1 !
summer term 2015 ⋅ M. Werner
7 / 49
osg.informatik.tu-chemnitz.de
summer term 2015 ⋅ M. Werner
8 / 49
osg.informatik.tu-chemnitz.de
. . . die das Problem versch¨arfende Variante bringt weitere Jobs ins Spiel:
Real-Time Systems – Dependencies
Real-Time Systems – Dependencies
4.2 Access Control
4. mittel
priorisierte Jobs verdr¨angen den niedrig priorisierten Job und
4.2 Access Control
blockieren indirekt den h¨
oher priosisierten Job noch l¨anger
Pathfinder’s
! kritischer Problem
Abschnitt oder Betriebsmittel: Unteilbarkeit ist das Problem
High-priority task∗ controls
transactions
over 1553 bus
bc sched
wosch
WS 2006/07
EZS
▸ tests termination of bc dist
bc dist High-priority task, controls collection of transaction results
6 Vorrangsteuerung 6.4 Priorit¨
atsverletzung und Priorit¨
atsumkehr
▸ communicates mostly by buffered shared memory
What really happened on Mars?
Pathfinder’s Problem (cont.)
6 - 26
▸
Hardware cycle of 125 ms
▸
Pipe communication uses a semaphore
▸
Shortly after start of communication,
ASI/MET is blocked á bc dist can not
read successfully from pipe
▸
bc sched determines non-termination of
bc dist and initiates reset
(Forts.)
ASI/MET
Low-priority
task, collects meteorological data
Aufbau
eines Buszyklus
▸ communicates with bc dist by IPC (pipe)
125ms
bus
bc_dist
bc_sched
any
t1
∗
any
t2
t3
t1 Transaktion startet hardware-kontrolliert an
highest priority at all, except VxWorks internal task “tExec”
t2 Busverkehr ist zur Ruhe gekommen, bc dist
any
t4
t5
▸ More in detail: Glenn Reeves (Mars Pathfinder Flight Software Cognizant Engineer): “What really happened on Mars?”,
http://research.microsoft.com/en-us/um/people/mbj/Mars Pathfinder/Authoritative Account.
html
t1
einer 8 Hz Grenze
wird ausgel¨
ost
summer
⋅ M.die
Werner
9 / 49
t3 bcterm
dist2015
hat
Datenverteilung abgeschlossen
osg.informatik.tu-chemnitz.de
summer term 2015 ⋅ M. Werner
10 / 49
osg.informatik.tu-chemnitz.de
t4 bc sched wird ausgel¨
ost, setzt Transaktion f¨
ur n¨achsten Buszyklus auf
t5 bc sched hat seine Aufgabe f¨
ur diesen Zyklus beendet
Real-Time Systems – Dependencies
Real-Time Systems – Dependencies
4.2 Access Control
! Intervalle
[t1Control
, t2 ), [t3 , t4 ), [t5 , t1 ) standen u.a. ASI/MET zur Verf¨
ugung
4.2 Access
wosch
WS 2006/07
EZS
6 - 28
Measures against Priority Inversion
There are a number of approaches to deal with priority inversion, e.g.:
▸
Non-preemptive critical sections
▸
Priority inheritance protocol
▸
Priority ceiling protocol
▸
Stack resource policy
summer term 2015 ⋅ M. Werner
11 / 49
osg.informatik.tu-chemnitz.de
▸
Non-preemptive critical sections, NPCS
▸
Idea: Within a critical section, a job must not be interrupted
▸
Example: 3 jobs Ji (tr , e, td ) π1 > π2 > π3
J1 = (6, 5, 14) J2 = (2, 7, 17) J3 = (0, 6, 18)
summer term 2015 ⋅ M. Werner
12 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Real-Time Systems – Dependencies
4.2 Access Control
NPCS – Discussion
Priority Inheritance Protocol
▸
No priority inversion possible
▸
Priority inheritance protocol (PIP)
▸
Maximal blocking time is bounded
▸
Idea: If a job blocks the access of a higher-priority job to a resource, the priority of
the blocking job is raised
▸
Assumption:
Blocking times
tb,i (CS) ≤ max ta,k (CS)
▸
i+1≤k≤n
▸
▸
▸
▸
▸
ta,i ∶ duration of CS in job Jk
Tasks are ordered by priority
Scheduling policy with fixed priorites
Algorithm:
▸
Each job is scheduled due its priority
▸
(Ji ▹R) ∧ (Jk ◇R) ↝ Jk ê Ji
i.e., if a job Ji requires a resource R hold by Jk , Ji is blocked
Easy to implement
▸
If πi > πk , then πk is temporary raised to πi
Disadvantage: Even uninvolved, high-priority jobs can be blocked
▸
Once Jk releases R, Jk resumes its original priority
summer term 2015 ⋅ M. Werner
13 / 49
osg.informatik.tu-chemnitz.de
summer term 2015 ⋅ M. Werner
Real-Time Systems – Dependencies
4.2 Access Control
Priority Inheritance Protocol – Example 2
Example 4.1
▸
▸
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Priority Inheritance Protocol – Example 1
▸
14 / 49
Example 4.2
3 jobs Ji (tr , e, td ):
J1 = (6, 5, 14) J2 = (2, 7, 17)
▸
5 jobs
π1 > π2 > π3
▸
π1 > π2 > π3 > π4 > π5
All require R
▸
Two resources: orange and green
J1
J3 = (0, 6, 18)
1
J2
2
2 2
J3 3 3
0
2
2
summer term 2015 ⋅ M. Werner
Ji
J1
J2
J3
J4
J5
1 1
4
1
6
8
15 / 49
3
10
12
14
16
18
osg.informatik.tu-chemnitz.de
t
tr,i
7
5
4
2
0
ei
3
3
2
6
6
resources
[orange, dacc = 1, tacc = 1]
[green, dacc = 1, tacc = 1]
–
[orange, dacc = 4, tacc = 1], [green, dacc = 1.4, tacc = 3]
[green, dacc = 4, tacc = 1]
tacc : time of access, dacc ∶ duration of access (both in relation to execution time)
summer term 2015 ⋅ M. Werner
16 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Real-Time Systems – Dependencies
4.2 Access Control
Priority Inheritance Protocol – Example 2 (cont.)
Priority Inheritance Protocol – Discussion
J1
J2
▸
No priority inversion
▸
Transparent to programmer
▸
Method is transitive á multiple inheritance is possible
Two kinds of blocking:
▸
J3
▸
▸
J4
▸
▸
J5
0
2
4
6
8
summer term 2015 ⋅ M. Werner
10
12
14
16
17 / 49
18
20
Blocking duration not minimal á chained (or transitive/cascading) blocking
Deadlocks are possible
▸
t
osg.informatik.tu-chemnitz.de
Priority-Ceiling Protocol (PCP)
▸
Idea: resources features priorities; access considers resource and task priorities
Assumptions:
▸
▸
▸
Fixed priorities (e.g., RMS)
It is a priori known, which jobs requires (eventually) which resource
Initialization: assign each job its static priority: ∀Ji , πi′ ∶= πi
Scheduling: schedule all jobs according their current priorities πi′
Access: If Ji ▹Rj :
▸
▸
▸
Parameter:
▸
πi′ : current priority of Ji
▸
▸
▸
may differ from static priority
▸
Πk : Priority ceiling of resource Rk , Πk = max (πi )
Ji ⊳Rk
▸
▸
Ji◇Rk
▸
ˆ
If ∃
/ i, k, Ji ◇Rk , then Π(t)
=⊥ (lowest value)
summer term 2015 ⋅ M. Werner
19 / 49
osg.informatik.tu-chemnitz.de
ˆ á Ji gets Rj
If Rj is free and πi′ > Π
ˆ and Ji holds resource Rk with Πk = Π
ˆ
If Rj is free, πi′ ≤ Π,
á Rj is assigned to Ji
Else áê Ji
′
′
Inheritance: If Jm êJi á Jm inherits priority from Ji : πm
= max(πm
, πi′ )
ˆ
ˆ
Π(t):
(Current) priority ceiling at time t: Π(t)
= max (Πk )
▸
osg.informatik.tu-chemnitz.de
Priority-Ceiling Protocol – Algorithm
▸
▸
18 / 49
Real-Time Systems – Dependencies
4.2 Access Control
Priority-Ceiling Protocol
▸
Cf. Example 2: assume, J5 requires “orange” at t = 6
á deadlock
summer term 2015 ⋅ M. Werner
Real-Time Systems – Dependencies
4.2 Access Control
▸
direct blocking of competing jobs
indirect blocking (push-trough blocking) due to priority raise
ˆ job Jm that holds resource Rk with Πk = Π
ˆ is the
In case, R is free but πi′ ≤ Π,
blocking one
If Jm releases Rj , Jm resumes its previous priority
summer term 2015 ⋅ M. Werner
20 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Real-Time Systems – Dependencies
4.2 Access Control
Priority-Ceiling Protocol – Algorithm (cont.)
Priority Ceiling Protocol – Example
▸
Use job set from Example 4.2
priority
J1
task 1
J2
J3
access to
task 2
J4
preemption
J5
0
Π(t)
1
2
3
4
5
access to
task 3
access to
access to
access to
summer term 2015 ⋅ M. Werner
21 / 49
osg.informatik.tu-chemnitz.de
Theorem 4.3
No deadlocks occur during the priority-ceiling protocol.
▸
▸
22 / 49
Extends PCP
▸
Idea: delay a job until it may run without interruption
Assumptions:
▸
▸
16
18
20 t
osg.informatik.tu-chemnitz.de
▸
▸
▸
▸
Fixed or variable priorities (i.e., also EDF)
Can deal with multiple resource instances
πi (t): priority of job Ji
λi : preemption level of a job
νk (t): number of (still) available instances of a resource Rj
νmax,j : overall number of instances of a resource Rj
µk (Ji ): maximal by Ji demanded number of instances of resource Rj
∗ Please note:
23 / 49
osg.informatik.tu-chemnitz.de
[Bak91]
Parameter:
▸
direct blocking
blocking due to inheritance
blocking due to ceiling
summer term 2015 ⋅ M. Werner
14
▸
[SRL90] )
Blocking durations are bounded
Three kinds of blocking
▸
12
Stack resource policy∗ (SRP)
▸
▸
10
▸
▸
▸
8
Stack Resource Policy
Deadlock-free:
Proof: homework or tutorial
(if interested, please consult
6
Real-Time Systems – Dependencies
4.2 Access Control
Priority-Ceiling Protocol – Discussion
▸
4
summer term 2015 ⋅ M. Werner
Real-Time Systems – Dependencies
4.2 Access Control
▸
2
in literature, one finds different names for this and similar approaches.
summer term 2015 ⋅ M. Werner
24 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Real-Time Systems – Dependencies
4.2 Access Control
Preemption Level
Ceiling
▸
▸
Statically assigned to a task (i.e., all jobs)
Ceiling of a resource changes with time
Rule for Preemption Levels
Πk (νk ) = max({0} ∪ {λi ∶ νk < µk (Ji )})
If a job Ja arrives after Jb and πa > πb , than λa > λb .
▸
For RMS: λi equals πi
▸
Ceiling is the maximum preemption level of all tasks with non-satisfiable demands
▸
For EDF: λi > λj ⇔ Di < Dj (Dx : relative deadlines)
▸
If there are sufficient number of resource’s instances (e.g., all): Πk = 0
▸
The current ceiling is the maximum of all resource ceilings, again
ˆ = max(Πk (νk ))
Π
k
π1 < π2 but λ1 < λ2
π1 > π2 but λ1 < λ2
▸
summer term 2015 ⋅ M. Werner
25 / 49
osg.informatik.tu-chemnitz.de
Remember: νk gives the number of available exemplars
summer term 2015 ⋅ M. Werner
Real-Time Systems – Dependencies
4.2 Access Control
Stack Resource Policy – Algorithm
Given: three jobs and three kinds of resources
λi µR1 (Ji ) µR2 (Ji )
J1 3
1
0
J2 2
2
1
J3 1
3
1
µR3 (Ji )
1
3
1
1. Job are scheduled due to the basic approach (e.g., RMS or EDF)
2. A (ready) job must not run, until
▸
▸
Then, the following ceilings have to be considered
νmax Πk (3) Πk (2) Πk (1)
R1
3
0
1
2
0
R2
1
R3
3
0
2
2
summer term 2015 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Ceiling – Example
▸
26 / 49
27 / 49
▸
it has the highest priority of all ready jobs
and
its preemption level is greater than the current ceiling
Πk (0)
3
2
3
osg.informatik.tu-chemnitz.de
summer term 2015 ⋅ M. Werner
28 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Real-Time Systems – Dependencies
4.2 Access Control
Stack Resource Policy – Example
Stack Resource Policy – Example 2
▸ Again, we use job set from Example 4.2
J1
▸
Consider following three jobs:
J2
J1
—
—
—
—
reserve(R3 ,1)
reserve(R1 ,1)
—
—
free(R1 )
free(R3 )
—
—
—
—
J3
J4
J5
0
2
4
6
8
10
12
14
16
20 t
18
ˆ
Π(t)
1
2
3
4
5
summer term 2015 ⋅ M. Werner
29 / 49
osg.informatik.tu-chemnitz.de
summer term 2015 ⋅ M. Werner
Real-Time Systems – Dependencies
4.2 Access Control
30 / 49
J3
—
—
reserve(R2 ,1)
reserve(R1 ,3)
—
—
free(R1 )
free(R2 )
—
—
reserve(R3 ,1)
—
—
free(R3 )
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.2 Access Control
Stack Resource Policy – Example 2
▸
J2
—
—
—
reserve(R3 ,3)
reserve(R2 ,1)
—
—
free(R2 )
free(R3 )
—
—
—
reserve(R1 ,2)
—
—
free(R1 )
Stack Resource Policy – Discussion
● νR1 = 3, ● νR2 = 1, ● νR3 = 3
J1
▸
In case of single exemplar resources, there is a simpler resource ceiling
J2
ΠR = max({0} ∪ {λi ∶ R could block Ji })
J3
0
2
4
6
8
10
12
14
16
18
20
ˆ
Π(t)
1
2
3
▸
▸
Schedule differs from priority-ceiling protocol
▸
▸
Once a job has started, it will never blocked (but, if necessary, interrupted)
All jobs may share a stack
▸
No deadlocks
t
á The name derives from this fact
ˆ at t = 4 and t = 5, since a sufficient
Please note, that there is no change of Π
number of resource items is still available
summer term 2015 ⋅ M. Werner
31 / 49
osg.informatik.tu-chemnitz.de
summer term 2015 ⋅ M. Werner
32 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.3 Blocking Times
Real-Time Systems – Dependencies
4.3 Blocking Times
Blocking Times and Feasability Criterions
Assumptions
▸
Access during critical sections
▸
The execution time CS of a critical section is bounded
Definition 4.4
▸
A job may enter more than one critical sections
The blocking time tb,i of a job Ji is the duration Ji is delayed at the access to a
resource, due to an access of a lower-priority resource to the same resource.
▸
Critical sections may be nested, but not partially intersecting
in sequence
▸
Delays due to interruption (preemption) are not blocking times
▸
Delays due to priority inheritance are (indirect) blocking times
nested
partially intersecting
▸
summer term 2015 ⋅ M. Werner
33 / 49
osg.informatik.tu-chemnitz.de
No deadlocks
summer term 2015 ⋅ M. Werner
Real-Time Systems – Dependencies
4.3 Blocking Times
34 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.3 Blocking Times
Blocking Times for NPCS
Feasibility
▸
For known blocking times, feasibility can be tested by TDA
Time demand of each task can be expanded by blocking
Modified time demand function for task Ti :
▸
Different for fixed-priority policies and variable-priority policies
▸
▸
Consider fixed priorities
▸
Theorem 4.5
Each job Ji can blocked at most once, for the duration of the longest critical section of all
jobs with a lower priority than the priority of Ji .
i−1
wi (t) = ei + bi + ∑ ⌈
k=1
bi ≤ max (CSj )
πj <πi
▸
▸
t
⌉ ek
Pk
Again, feasibility is described by inequation of Theorem 3.6
Please note: Even jobs without any critical section may be blocked!
∀i ∶ (∃t, 0 < t ≤ Pi ∶ wi (t) ≤ t)
summer term 2015 ⋅ M. Werner
35 / 49
osg.informatik.tu-chemnitz.de
summer term 2015 ⋅ M. Werner
36 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.3 Blocking Times
Real-Time Systems – Dependencies
4.3 Blocking Times
Blocking Times for NPCS with EDF
▸
Feasability under EDF
Consider EDF
Theorem 4.6
▸
Known blocking times can be handled as additional tasks
In EDF, a job Ji can only be blocked by Jk , if Pk > Pi
▸
Thus, a task set is feasible if
▸
Proof:
Feasability
1. Ji must feature a higher deadline á earlier deadline
2. Jk must be executed when Ji arrives, i.e. rk < ri
3. Together, both is only true for Pk>Pi
▸
∀i ∶
Thus, for jobs ordered by periods:
n
e k bi
+
≤1
Pi
k=1 Pk
∑
bi ≤ max (CSj )
Pj >Pi
summer term 2015 ⋅ M. Werner
37 / 49
osg.informatik.tu-chemnitz.de
summer term 2015 ⋅ M. Werner
Real-Time Systems – Dependencies
4.3 Blocking Times
38 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.3 Blocking Times
Blocking Times for PIP
Blocking Times for PIP (cont.)
Observations
▸
▸
Lemma 4.7
Let JH and JL be two jobs with πH > πL
Then:
B-1: Independent of the number of shared resources, JL can block JH only for the
duration of one critical section (that may include other nested critical sections)
B-2: A resource Rk may indirectly block JH , if Rk is accessed by both, a low-priority job
JL and a third job JM that has (or can gain) the same or higher priority as JH
B-3: Casading blocking only happens with nested critical sections
summer term 2015 ⋅ M. Werner
39 / 49
osg.informatik.tu-chemnitz.de
If for a given job JH with priority πH exist n jobs J1 , . . . , Jn with lower priority, JH can
blocked at most for n critical sections (once per job)
Proof:
Regarding 1, a job Ji can block JH at most once. This is true for all n low-priority jobs.
summer term 2015 ⋅ M. Werner
40 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.3 Blocking Times
Real-Time Systems – Dependencies
4.3 Blocking Times
Blocking Times for PIP (cont.)
Blocking Times for PIP (cont.)
Lemma 4.8
Theorem 4.9
A resource R may block a job JH at most once.
With PIP, a job J may be delayed at most for the duration of min(n, m) critical sections,
where n is the number of lower-priority jobs and m the number of resources shared with
lower-priority jobs.
Proof:
▸
▸
If a low-priority job JL does not access R at start of JH , there is no blocking, due
to preemption
At starting time of JH there is at most one job that accesses R
summer term 2015 ⋅ M. Werner
41 / 49
▸
Proof: follows from Lemmata 4.7 and 4.8
▸
Please note: In difference to NPSC, only jobs and resources related to J are
relevant.
osg.informatik.tu-chemnitz.de
summer term 2015 ⋅ M. Werner
Real-Time Systems – Dependencies
4.3 Blocking Times
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.3 Blocking Times
Blocking Times for PCP
Proof of Theorem 4.10
▸
▸
Theorem 4.10
Proof by contradiction
Assumption: JH is blocked for more than one critical section
▸
In PCP, a job J can be blocked at most for the duration of one critical section.
▸
without loss of generality: two jobs, J1 and J2 , withπ2 < π1 < πH
Case distinction
1. If J1 enters the critical section first, J2 will not because of preemption á
contradiction
2. If J2 enters a critical section first, let Π∗2 the ceiling of all resources of J2
Please note: preemption is not blocking
▸
▸
▸
summer term 2015 ⋅ M. Werner
42 / 49
43 / 49
osg.informatik.tu-chemnitz.de
When J1 enters a critical section, it must be true: π1 > Π∗2
Also, it must be true πH ≤ Π∗2 (since JH is blocked, regarding assumption)
Follows: π1 > Π∗2 ≤ πH , i.e., πH < π1 á contradiction
summer term 2015 ⋅ M. Werner
44 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.3 Blocking Times
Real-Time Systems – Dependencies
4.3 Blocking Times
Blocking Times SRP
Actual Cases
▸
▸
▸
The actual blocking times are frequently shorter than the times given by the
theorems
Derive by considering resource requirement graph
Consider following example for PCP
▸
Theorem 4.11
PCP, π1 > π2 > ⋯ > π6
J1
In SRP, a job J can be blocked at most for the duration of one critical section.
▸
Proof is similar to proof of Theorem 4.10
(consider λi in place of πi )
RX
10
J2
1
J3
6
J4
8
J5
summer term 2015 ⋅ M. Werner
45 / 49
osg.informatik.tu-chemnitz.de
4
J6
46 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
4.3 Blocking Times
Example
Comparison
J1
RX
10
▸ Three kinds of blocking
J2
1
▸ Create blocking table
J3
6
J4
maximal blocking time
8
J5
priority-inher blocked
by
J2 J3 J4 J5 J6
J2 J3 J4 J5 J6
J1
6
2
J2
∗
5
∗
J3
∗ ∗
4
∗
J4
∗ ∗ ∗
∗
J5
∗ ∗ ∗ ∗
∗
∗: No blocking possible (preemption)
6
∗ 5
∗ ∗
∗ ∗ ∗
2
2
4
4
priority-ceiling
blocked by
J2 J3 J4 J5
∗
∗
∗
∗
6
∗ 5
∗ ∗
∗ ∗ ∗
RZ
J6
2
2
4
protocol
NPSC
PIP
PCP
SRP
priorities
fixed or variable
fixed
fixed
fixed or
variable
blocking time [#CS]
1†
min(n, m)
1
1
when blocked
preemption
access
access
preemption
transparent
yes
yes
no
no
deadlock-free
yes
no
yes
yes
2
RY
5
▸ Row maximum provides for each job the
directly blocked by
RZ
summer term 2015 ⋅ M. Werner
Real-Time Systems – Dependencies
4.3 Blocking Times
2
RY
5
4
J6
max
6
6
5
4
4
† Even for jobs without resource conflicts
summer term 2015 ⋅ M. Werner
47 / 49
osg.informatik.tu-chemnitz.de
summer term 2015 ⋅ M. Werner
48 / 49
osg.informatik.tu-chemnitz.de
Real-Time Systems – Dependencies
References
[But05]
Giorgio C. Buttazzo. Hard Real-Time Computing Systems. Springer, 2005, Kapitel 7
[SRL90]
Lui. Sha, Ragunathan. Rajkumar, and John.P. Lehoczky. “Priority inheritance protocols:
an approach to real-time synchronization”. In: IEEE Transactions on Computers 39.9 (Sept.
1990), pp. 1175–1185. ISSN: 0018-9340. DOI: 10.1109/12.57058
[Bak91]
Theodore P. Baker. “Stack-based scheduling of realtime processes”. In: Real-Time
Systems 3.1 (1991), pp. 67–99
summer term 2015 ⋅ M. Werner
49 / 49
osg.informatik.tu-chemnitz.de