6. Deadlocks

1
6. Deadlocks

• 6.1 Deadlocks with Reusable and Consumable
  Resources
• 6.2 Approaches to the Deadlock Problem
• 6.3 A System Model
• Resource Graphs
• State Transitions
• Deadlock States and Safe States
• 6.4 Deadlock Detection
• Reduction of Resource Graphs
• Special Cases of Deadlock Detection
• Deadlock Detection in Distributed Systems
• 6.5 Recovery from Deadlock
• 6.6 Dynamic Deadlock Avoidance
• Claim Graphs
• The Bankers Algorithm
• 6.7 Deadlock Prevention

2
Deadlocks

• Informal definition Process is blocked on
  resource that will never be released.
• Deadlocks waste resources
• Deadlocks are rare
• Many systems ignore them
• Resolved by explicit user intervention
• Critical in many real-time applications
• May cause damage, endanger life

3
Reusable/Consumable Resources

• Reusable Resources
• Number of units is constant
• Unit is either free or allocated no sharing
• Process requests, acquires, releases units
• Examples memory, devices, files, tables
• Consumable Resources
• Number of units varies at runtime
• Process may create new units
• Process may consume units
• Examples messages, signals

4
Examples of Deadlocks

• p1 ... p2 ...
• open(f1,w) open(f2,w)
• open(f2,w) open(f1,w)
• ... ...
• Deadlock when executed concurrently
• p1 if (C) send(p2,m) p2 ...
• while(1)...
  while(1)...
• recv(p2,m)
  recv(p1,m)
• send(p2,m)
  send(p1,m)
• ...
  ...
• Deadlock when C not true

5
Deadlock, Livelock, Starvation

• Deadlock Processes are blocked
• Livelock Processes run but make no progress
• Both deadlock and livelock lead to starvation
• Starvation may have other causes
• ML scheduling where one queue is never empty
• Memory requests unbounded stream of 100MB
  requests may starve a 200MB request

6
Approaches to Deadlock Problem

• Detection and Recovery
• Allow deadlock to happen and eliminate it
• Avoidance (dynamic)
• Runtime checks disallow allocationsthat might
  lead to deadlocks
• Prevention (static)
• Restrict type of request and acquisitionto make
  deadlock impossible

7
System Model for Deadlock Detection, Avoidance,
etc.

• Assumptions
• When a process requests a resource, either the
  request is fully granted or the process blocks
• No partial allocation
• A process can only release resources that it
  holds
• Resource graph
• Vertices are processes, resources, resource units
• Edges (directed) represent requests and
  allocations of resources

8
System Model Resource Graph

• Resource graph
• Process Circle
• Resource Rectangle with small circles for each
  unit
• Request Edge from process to resource class
• Allocation Edge from resource unit to process

Figure 6-1
9
System Model State Transitions

• Request Create new request edge pi?Rj
• pi has no outstanding requests
• number of edges between pi and Rj cannot exceed
  total units of Rj
• Acquisition Reverse request edge to pi?Rj
• All requests of pi are satisfiable
• pi has no outstanding requests
• Release Remove edge pi?Rj

Figure 6-2
10
System Model

• A process is blocked in state S if it cannot
  request, acquire, or release any resource.
• A process is deadlocked in state S if it is
  currently blocked now and remains blocked in all
  states reachable from state S
• A state is a deadlock state if it contains a
  deadlocked process.
• State S is a safe state if no deadlock state can
  be reached from S by any sequence of request,
  acquire, release.

11
Example

• 2 processes p1 , p2 2 resources R1, R2,
• p1 and p2 both need R1 and R2
• p1 requests R1 before R2 and releases R2 before
  R1
• p2 requests R2 before R1 and releases R1 before
  R2

Figure 6-3 Transitions by p1 only
12
Example

• p1 and p2 both need R1 and R2
• p1 requests R1 before R2 and releases R2
  before R1
• p2 requests R2 before R1 and releases R1
  before R2

Figure 6-4 Transitions by p1 and p2
13
Deadlock Detection

• Graph Reduction Repeat the following
• Select unblocked process p
• Remove p and all request and allocation edges
• Deadlock ? Graph not completely reducible.
• All reduction sequences lead to the same result.

Figure 6-5
14
Special Cases of Detection

• Testing for whether a specific process p is
  deadlocked
• Reduce until p is removed or graph irreducible
• Continuous detection
• Current state not deadlocked
• Next state T deadlocked only if
• Operation was a request by p and
• p is deadlocked in T
• Try to reduce T by p

15
Special Cases of Detection

• Immediate allocations
• All satisfiable requests granted immediately
• Expedient state state with no satisfiable
  request edges
• If all requests are granted immediately, all
  states are expedient.
• Not expedient (p1-gtR1)

16
Special Cases of Detection

• Immediate allocations, continued.
• Knot A set K of nodes such that
• Every node in K reachable from any other node in
  K
• No outgoing edges from any node in K
• Knot in expedient state ? Deadlock
• Reason
• All processes in K must have outstanding requests
  
• Expedient state means requests not satisfiable
• (Remove R2-gtp1 knot R2,p3,R3,p5)
• (Reverse edge p1-gtR1) expedient state

17
Special Cases of Detection

• For single-unit resources, cycle ? deadlock
• Every p must have a request edge to R
• Every R must have an allocation edge to p
• R is not available and thus p is blocked
• Wait-For Graph (wfg) Show only processes
• Replace p1?R? p2 by p1 ? p2 p1 waits for p2

Figure 6-6
18
Deadlock detection in Distributed Systems

• Central Coordinator (CC)
• Each machine maintains a local wfg
• Changes reported to CC
• CC constructs and analyzes global wfg
• Problems
• Coordinator is a performance bottleneck
• Communication delays may cause phantom deadlocks

Figure 6-7
19
Detection in Distributed Systems

• Distributed Approach
• Detect cycles using probes.
• If process pi blocked on pj , it launches probe
  pi ? pj
• pj sends probe pi ? pj ? pk along all request
  edges, etc.
• When probe returns to pi, cycle is detected

Figure 6-8
20
Recovery from Deadlock

• Process termination
• Kill all processes involved in deadlock or
• Kill one at a time. In what order?
• By priority consistent with scheduling
• By cost of restart length of recomputation
• By impact on other processes CS,
  producer/consumer
• Resource preemption
• Direct Temporarily remove resource (e.g.,
  Memory)
• Indirect Rollback to earlier checkpoint

21
Dynamic Deadlock Avoidance

• Maximum Claim Graph
• Process indicatesmaximum resources needed
• Potential request edgepi?Rj (dashed)
• May turn intoreal request edge

Figure 6-9
22
Dynamic Deadlock Avoidance

• Theorem Prevent acquisitions that do not produce
  a completely reducible graph? All state are
  safe.
• Bankers algorithm (Dijkstra)
• Given a satisfiable request, p?R, temporarily
  grant request, changing p?R to R?p
• Try to reduce new claim graph, treating claim
  edges as actual requests.
• If new claim graph is completely reducible
  proceed. If not, reverse temporary acquisition
  R?p back to p?R
• Analogy with banking resources correspond to
  currencies, allocations correspond to loans,
  maximum claims correspond to credit limits

23
Example of bankers algorithm

• Claim graph (a). Which requests for R1 can
  safely be granted?
• If p1s request is granted, resulting claim graph
  (b) is reducible (p1,p3,p2).
• If p2s request is granted, resulting claim graph
  (c) is not reducible.
• Exercise what about p3s request?

Figure 6-10
24
Dynamic Deadlock Avoidance

• Special Case Single-unit resources
• Check for cycles after tentative
  acquisitionDisallow if cycle is found (cf. Fig
  6-11(a))
• If claim graph contains no undirected cycles,all
  states are safe (cf. Fig 6-11(b))(Because no
  directed cycle can ever be formed.)

Figure 6-11
25
Deadlock Avoidance Another Approach

• Restrict waits to avoid wait for cycles.
• Each process has timestamp. Ensure that either
• Younger process never waits for older process or
• Older process never waits for younger process
• When process R requests resource that process H
  holds (two variants)
• Wait/die algorithm (Younger process never waits)
• If R is older than H, R waits
• If R is younger than H it dies, restarts
• Wound/wait algorithm (Older process never waits)
• If R is older than H, resources is preempted
  (which may mean process is killed, restarted)
• If R is younger than H, R waits
• Restarted process keeps old timestamp

26
Comparison of deadlock avoidance schemes

• Wound/wait and wait/die kill processes even when
  there is no deadlock (more aggressive).
• Wait/die generally kills more processes than
  wound/wait, but generally at an earlier stage
• Note Wait/die and Wound/wait are sometimes
  classified as prevention schemes rather than
  avoidance schemes

27
Deadlock Prevention

• Deadlock requires the following conditions
• Mutual exclusion
• Resources not sharable
• Hold and wait
• Process must be holding one resourcewhile
  requesting another
• Circular wait
• At least 2 processes must beblocked on each other

28
Deadlock Prevention

• Eliminate mutual exclusion
• Not possible in most cases
• Spooling makes I/O devices sharable
• Eliminate hold-and-wait
• Request all resources at once
• Release all resources before a new request
• Release all resources if current request blocks
• Eliminate circular wait
• Order all resources SEQ(Ri) ? SEQ(Rj)
• Process must request in ascending order

29

• History
• Originally developed by Steve Franklin
• Modified by Michael Dillencourt, Summer, 2007
• Modified by Michael Dillencourt, Spring, 2009
• Modified by Michael Dillencourt, Winter, 2010