Deadlock

1
Deadlock

• CSE451
• Andrew Whitaker

2
Review What Can Go Wrong With Threads?

• Safety hazards
• Program does the wrong thing
• Liveness hazards
• Program never does the right thing
• Performance hazards
• Program is too slow due to excessive
  synchronization

3
A Liveness Hazard Starvation

• A thread is ready, but the scheduler does not
  select it to run
• Can be caused by shortest-job-first scheduling

4
Deadlock

• Each thread is waiting on a resource held by
  another thread
• So, there is no way to make progress

Thread 1
Thread 2
Thread 3
5
Deadlock, Illustrated
6
Necessary Conditions for Deadlock

• Mutual exclusion
• Resources cannot be shared
• e.g., buffers, locks
• Hold and wait (subset property)
• A thread must hold a subset of its resource needs
• And, the thread is waiting for more resources
• No preemption
• Resources cannot be taken away
• Circular wait
• A needs a resource that B has
• B has a resource that A has

7
Resource Allocation Graph with a Deadlock
P gt R request edge R gt P assignment edge
Silberschatz, Galvin and Gagne ?2002
8
Cycle Without Deadlock
P gt R request edge R gt P assignment edge
Why is there no deadlock here?
Silberschatz, Galvin and Gagne ?2002
9
Graph Reduction

• A graph can be reduced by a thread if all of that
  threads requests can be granted
• Eventually, all resources by the reduced thread
  will be freed
• Miscellaneous theorems (Holt, Havender)
• There are no deadlocked threads iff the graph is
  completely reducible
• The order of reductions is irrelevant
• (Detail resources with multiple units)

10
Approaches to Deadlock

• Avoid threads
• Deadlock prevention
• Break up one of the four necessary conditions
• Deadlock avoidance
• Stay live even in the presence of the four
  conditions
• Detect and recover

11
Approach 1 Avoid Threads

• Brain dead solution avoid deadlock by avoiding
  threads
• Example GUI frameworks
• Typically use a single event-dispatch thread

12
Approach 2 Prevention

• Can we eliminate
• Mutual exclusion?
• Hold and wait (subset property)?
• No Preemption?
• Circular waiting?

13
Lock Ordering

• We can avoid circular waiting by acquiring
  resources in a fixed order
• Example Linux rename operation
• Each open file has a semaphore
• Both semaphores must be held during file
  operations
• Linux always uses the same order for down
  operations
• Semaphore at the lowest memory address goes first

14
Rename Example

• Process 1 rename (foo.txt,bar.txt)
• Process 2 rename (bar.txt,foo.txt)

foo semaphore
bar semaphore
bar semaphore
foo semaphore
down()
down()
up()
up()
foo semaphore
bar semaphore
bar semaphore
foo semaphore
down()
down()
up()
up()
15
Approach 3 Avoidance

• Intuition the four conditions do not always lead
  to deadlock
• necessary but not sufficient
• We can stay live if we know the resource needs of
  the processes

16
Bankers Algorithm Overview

• Basic idea ensure that we always have an escape
  route
• The resource graph is reducible
• This can be enforced with the bankers algorithm
• When a request is made
• Pretend you granted it
• Pretend all other legal requests were made
• Can the graph be reduced?
• If so, allocate the requested resource
• If not, block the thread

17
Deadlock Avoidance in Practice

• Static provisioning
• Ensure that each active process/thread can
  acquire some minimum set of resources
• Use admission control to maintain this invariant
• This is closely related to the idea of thrashing
• Each thread needs some minimum amount of
  resources to run efficiently

18
Approach 4 Detection and Recovery

• Not commonly used
• Detection is expensive
• Recovery is tricky
• Possible exception databases

19
Deadlock Detection

• Detection algorithm (sketch)
• Keep track of who is waiting for resources
• Keep track of who holds resources
• Assume that all runnable processes release all
  their resources
• Does this unblock a waiting process?
• If yes, release that processs resources
• If processes are still blocked, we are deadlocked

20
Recovery

• Must back out of a resource allocation decision
• By preemption or by killing the process
• This is particularly problematic for lock-based
  deadlocks
• System can be in an inconsistent state