TDDD82
Secure Mobile Systems
Systems Software
Lecture 3: Deadlocks & Banker’s
Algorithm
Mikael Asplund
Real-time Systems Laboratory
Department of Computer and Information Science
Linköping University
Based on slides by Simin Nadjm-Tehrani and the Sliberschatz et al.
2014
Project course TDDD82
Systems software module
34 pages
Spring 2015
From last lecture
• How did it go with the exercise?
Project course TDDD82
Systems software module
2 of 34
Spring 2015
Program execution
...
TCTC
...
TC
TCT
...
...
TCA
T
TA
TCAK
TAC
...
TACT
TACK
...
TACKT
Project course TDDD82
Systems software module
3 of 34
Spring 2015
Correctness properties
●
Safety properties
–
●
Something bad will not happen
Liveness properties
–
Something good will happen (eventually)
Project course TDDD82
Systems software module
4 of 34
Spring 2015
Progress
●
A form of liveness
●
Mathematically defined within a given system model
●
–
Can be defined on system or process level
–
Typically ensures that if system is in some state s, then it will
reach some other state s' where some property P holds.
Implies freedom from:
–
Deadlock
–
Starvation
–
Livelock
Project course TDDD82
Systems software module
5 of 34
Spring 2015
Deadlock
Deadlock occurs when a group of processes are
locked in a circular wait (more on this soon).
Project course TDDD82
Systems software module
6 of 34
Spring 2015
Starvation/lockout
Starvation/lockout happens if some process
never gets hold of the resources because they
are always bypassed by some other processes
Project course TDDD82
Systems software module
7 of 34
Spring 2015
Livelock
1. Free
passage
2. Start
driving
3. Passage
blocked
4. Back
off
Livelock occurs when a group of processes are
stuck in a loop of actions where they stop each
other from progressing
Project course TDDD82
Systems software module
8 of 34
Spring 2015
Deadlock-freedom
●
Freedom from deadlock is fundamental
to any concurrent system
●
Necessary but not sufficient for progress!
●
Topic for the rest of this lecture
Project course TDDD82
Systems software module
9 of 34
Spring 2015
Earlier
• Mutual exclusion and condition
synchronisation
–
Semaphores
–
Monitors
–
Concurrent data structures
• Worked well for single resource
• What about multiple resources?
Project course TDDD82
Systems software module
10 of 34
Spring 2015
Simple deadlock situation
P1
Two semaphores
●
–
S1 for resource R1
–
S2 for resource R2
R1
R2
P2
Process P1:
Process P2:
wait(S2)
wait(S1)
wait(S1)
wait(S2)
...
...
signal(S1)
signal(S2)
signal(S2)
signal(S1)
Project course TDDD82
Systems software module
11 of 34
Spring 2015
Coffman conditions
Four necessary conditions for deadlock:
1. Mutual exclusion
Access to a resource is limited to one (or a
limited number of) process(es) at a time
2. Hold & wait
A process may hold a resource and wait for
another resource at the same time
Project course TDDD82
Systems software module
12 of 34
Spring 2015
3. Voluntary release
Resources can only be released by a
process voluntarily
4. Circular wait
There is a chain of processes where each
process holds a resource that is required
by another resource
Project course TDDD82
Systems software module
13 of 34
Spring 2015
Another classic example
P2
P1
rice
P5
P3
P4
Project course TDDD82
Systems software module
14 of 34
Spring 2015
A potential solution
process Philosopher;
loop
think;
<pick up left chopstick>
<pick up right chopstick>
eat;
<put down right chopstick>
<put down left chopstick>
end loop
end;
Project course TDDD82
Systems software module
15 of 34
Spring 2015
Deadlock elimination
Three approaches:
• Deadlock prevention
• Deadlock detection and treatment
• Deadlock avoidance
Project course TDDD82
Systems software module
16 of 34
Spring 2015
Deadlock prevention
...
...
...
...
...
...
...
Project course TDDD82
Systems software module
17 of 34
Spring 2015
Deadlock prevention
●
●
Ensure that at least one of the Coffman
conditions can never occur
E.g., prevent Hold&Wait
–
A process must acquire all resources at once
Project course TDDD82
Systems software module
18 of 34
Spring 2015
All at once
process Philosopher;
loop
think;
<pick up left and right
chopsticks if free>
eat;
<put down left and right
chopsticks>
end loop
end;
Project course TDDD82
Systems software module
19 of 34
Spring 2015
Consider following scenario
P1
P3
P2
P1
P1
P1
P3
P3
P3
...
wants to eat, takes left & right stick
wants to eat, takes left & right stick
wants to eat, must wait
releases left & right stick
thinks
wants to eat, takes left & right stick
releases left & right stick
thinks
wants to eat, ...
Project course TDDD82
Systems software module
20 of 34
Spring 2015
Absence of cycles
●
●
Absence of cycles in the dynamic
resource allocation graph guarantees
absence of deadlock
Cicular wait can also be prevented by
having priorities of processes and
resources (e.g., Immediate Ceiling
Protocol in Real-time scheduling)
Project course TDDD82
Systems software module
21 of 34
Spring 2015
Deadlock detection
...
...
...
...
...
...
Project course TDDD82
Systems software module
22 of 34
Spring 2015
Detection and fixing
Build a dynamic resource
allocation graph to detect deadlocks
P3
R1
P1
P2
R2
P4
Project course TDDD82
Systems software module
23 of 34
Spring 2015
Deadlock avoidance
...
...
...
...
...
...
Project course TDDD82
Systems software module
24 of 34
Spring 2015
Banker’s algorithm
• Upon each process request: Allocate
multiple resources that the process
requests, provided that:
– the request is up to a predefined max value
for each process and resource
(cumulatively)
– after each granting, the remaining resources
together with potential future releases, are
enough for all future allocations (up to the
max values)
Project course TDDD82
Systems software module
25 of 34
Spring 2015
Safe/unsafe/deadlock states
Project course TDDD82
Systems software module
26 of 34
Spring 2015
Rejecting a request
• When allocating a request does not lead
to a new “safe” state:
– Refuse to grant
• The request can be repeated in some
future state and get granted
Project course TDDD82
Systems software module
27 of 34
Spring 2015
Data structures
Let n = number of processes, and m = number of resources types.
Available: Vector of length m. If Available[j] = k, there are k
instances of resource type Rj available
Max: n x m matrix. If Max [i,j] = k, then process i may request
at most k instances of resource type Rj, Max[i] denotes the i'th
row.
Allocation: n x m matrix. If Allocation[i,j] = k then i is
currently allocated k instances of Rj, Allocation[i] denotes the i'th
row.
Need: n x m matrix. If Need[i,j] = k, then i may need k more
instances of Rj to complete its task, Need[i] denotes the i'th row.
Project course TDDD82
Systems software module
28 of 34
Spring 2015
Inputs and outputs of Banker's
Input:
Matrix Max, vector Available,
a given state Allocation, and
Request[i] for some process i
(* Request[i] =< Max[i] - Allocation[i] *)
Output:
Yes + new state, or
No + unchanged state
(Request[i] can not be allocated now)
Project course TDDD82
Systems software module
29 of 34
Spring 2015
Banker's algorithm
1. Need := Max – Allocation
2. Check whether Request[i]  Available
if not, return ”No”
3. Pretend that resources in Request[i] are to be allocated,
compute new state:
Allocation[i] := Allocation[i] + Request[i]
Need[i] := Need[i] - Request[i]
Available := Available – Request[i]
4. Test whether the new state is deadlock-avoiding (denoted
safe), in which case return ”Yes”.
Otherwise, return ”No” - roll back to the old state.
Project course TDDD82
Systems software module
30 of 34
Spring 2015
Testing for safe state
Start with a given Allocation
and check if it is safe (avoids future
deadlocks) according to the 3-step
algorithm below.
Project course TDDD82
Systems software module
31 of 34
Spring 2015
Illustration
• We’ll use an example to clarify how
testing for the safe state test works!
Project course TDDD82
Systems software module
32 of 34
Spring 2015
Safety algorithm data structures
Finish: n vector with Boolean values (initially
false)
Work : m vector denotes the changing resource set
as the processes become ready and release resources
(initially Work := Available)
Project course TDDD82
Systems software module
33 of 34
Spring 2015
Safety algorithm
1. Check if there is some process i for which Finish[i] = false
and for which Need[i]  Work. If there is no such process i, go
to step 3.
2. Free the resources that i has used to get finished:
Work := Work + Allocation[i]
Finish[i] := true
continue from step 1.
3. If Finish[i] = true for all i then the initial state is deadlockavoiding, otherwise it is not.
Project course TDDD82
Systems software module
34 of 34
Spring 2015
Summary
• Progress: Absence of deadlock,
starvation or livelock
• We have looked at ways to assure
deadlock-freedom in systems
• Banker's algorithm provides deadlockavoidance
Project course TDDD82
Systems software module
35 of 34
Spring 2015
Questions?
Project course TDDD82
Systems software module
36 of 34
Spring 2015