Reading material
TDDB47 Real-time Systems
• Chapter 13 of Burns & Wellings, in
particular 13.11.
Lecture 3: Scheduling &
Sharing resources
• Background reading on deadlocks
Simin Nadjm-Tehrani
Real-time Systems Laboratory
Department of Computer and Information Science
Linköping university
Undergraduate course on Real-time Systems
Linköping University
21 pages
Autumn 2005
Undergraduate course on Real-time Systems
Linköping University
2 of 21
Autumn 2005
This lecture and next
• Towards more dynamic scheduling:
Schedulability test
Theorem:
– Adapting for use of shared resources
– Offloading non-critical tasks to other
processors (distributed scheduling)
For n processes, RMS will guarantee their
schedulability if the total utilisation
U = C1/T1 + ... + Cn/Tn
does not exceed the guarantee level
Plus a little repetition on deadlocks…
G = n (2
Undergraduate course on Real-time Systems
Linköping University
(sufficient condition)
3 of 21
Autumn 2005
1/n
-1)
Undergraduate course on Real-time Systems
Linköping University
Shared resources
• Earlier methods for CPU allocation
(scheduling) assumed independence of
the tasks
• How to deal with a case where
concurrent processes are not
independent? ⇒ sharing resources
• How to achieve mutual exclusion for
multiple resources and still meet
deadlines?
Undergraduate course on Real-time Systems
Linköping University
5 of 21
Autumn 2005
4 of 21
Autumn 2005
Scheduling & sharing
• Assume that processes synchronise
using semaphores
• We use fixed priority scheduling but
relax the independence requirement
Undergraduate course on Real-time Systems
Linköping University
6 of 21
Autumn 2005
Priority Inversion
How to avoid it?
• A low priority process (P1) locks the
resource
• A high priority process (P2) has to wait
on the semaphore (blocked state)
• A medium priority process (P3)
preempts P1 and runs to completion
before P2!
Undergraduate course on Real-time Systems
Linköping University
• When P2 is blocked by P1 one raises the
priority of P1 to the same level as P2
temporarily
• Afterwards, when the semaphore is
released by P1, it goes back to its
normal priority level
• P3 can not interrupt P1 any more!
Undergraduate course on Real-time Systems
Linköping University
7 of 21
Autumn 2005
8 of 21
Autumn 2005
Priority inheritance
• Is transitive
• Guarantees an upper bound for blocking
time, since the high priority process P2
is blocked only under the interval that
P1 uses the resource
Example
Let P1 have lower priority than P2.
Preemption
S1
P1
S1?
Blocking
time
0
Deadlocks are possible! (as usual)
Undergraduate course on Real-time Systems
Linköping University
Si? denotes that process attempts to lock semaphore Si
9 of 21
Autumn 2005
Undergraduate course on Real-time Systems
Linköping University
10 of 21
Autumn 2005
Ceiling Protocols
Terminology
e.g. Immediate priority Ceiling Protocol
(ICP):
Note that:
• blocked – when waiting for a
resource
• not dispatched or preempted when waiting for processes with
higher fixed priority to execute
Undergraduate course on Real-time Systems
Linköping University
Blocking
S2?
S2
P2
But ...
Inheritance
• Each process that obtains a resource
inherits the resource’s ceiling priority the highest priority among all processes
that can possibly claim that resource
• When the resource is released, the
process priority returns to the normal
level (or to another engaged resource’s
ceiling)
11 of 21
Autumn 2005
Undergraduate course on Real-time Systems
Linköping University
12 of 21
Autumn 2005
Properties
• A process is blocked max once by
another process with lower priority
ICP & Deadlock
• The ICP prevents deadlocks (How?)
• Moreover, it prevents starvation (How?)
• The blocking delay is a function of the
length of the critical section
• Do not even need to use semaphores!
Undergraduate course on Real-time Systems
Linköping University
13 of 21
Autumn 2005
Undergraduate course on Real-time Systems
Linköping University
14 of 21
Autumn 2005
Deadlocks: necessary conditions
1. Mutual exclusion
Access to resource is limited to one (or a
limited number of) process(es) at a time
3. Voluntary release
Resources can only be released by a
process voluntarily
2. Hold & wait
Processes hold allocated resources and wait
for another resource at the same time
4. Circular wait
There is a chain of processes where each
process holds a resource that is required
by another resource
Undergraduate course on Real-time Systems
Linköping University
15 of 21
Autumn 2005
Undergraduate course on Real-time Systems
Linköping University
Deadlock elimination
16 of 21
Autumn 2005
Deadlock avoidance
...
Repetition from OS course:
...
• Deadlock avoidance
• Deadlock prevention
• Deadlock detection and treatment
...
...
...
...
Undergraduate course on Real-time Systems
Linköping University
17 of 21
Autumn 2005
Undergraduate course on Real-time Systems
Linköping University
18 of 21
Autumn 2005
Detection and fixing
Deadlock prevention
...
By building a dynamic resource
allocation graph to detect deadlocks
...
P3
R1
...
...
P1
...
P2
R2
...
P4
...
Undergraduate course on Real-time Systems
Linköping University
19 of 21
Autumn 2005
Questions?
Undergraduate course on Real-time Systems
Linköping University
21 of 21
Autumn 2005
Undergraduate course on Real-time Systems
Linköping University
20 of 21
Autumn 2005