Deadlocks
Vivek Pai / Kai Li
Princeton University
Bankgedanken
 How much money do banks keep?
 What is a bank run?
 How do you handle it?
2
Mechanics
 Dec 10 class canceled
 Readings – sketchy from here on
 Next project – VM
 Wednesday night midterm discussion
 8:30pm,
room 105
 Rough “grades” will be sent out soon
3
Let’s Talk About Deadlocks
wish I’d read
Chapter 3
4
Definitions
 Resources
 Preemptable (can be taken away): CPU
 Non-preemptable (cannot be taken away): Disk,
files, mutex, ...
 Starvation
 Processes/threads wait indefinitely
 Typical way to use a resource
 Request
 Use
 Release
5
Resource Allocation Graph
 Process A is holding
resource R
A
R
 Process B requests
resource S
B
 A cycle in the resource
allocation graph means
that there is deadlock
 If A requests for S while
holding R, and B
requests for R while
holding S, then
A
S
R
B
S
6
An Example
 A utility program
 copies a file from a
tape to disk
 prints the file to a
printer
 Resources
 tape
 disk
 printer
 A deadlock
A
tape
disk
printer
B
7
What Causes Deadlocks?
Guns don’t cause deadlocks – people do
8
Conditions for Deadlock
 Mutual exclusion condition
 Each resource is assigned to exactly one process
 Hold and Wait
 Multiple independent requests
 No preemption
 Resources cannot be taken away
 Circular chain of requests
Note: eliminating any condition eliminates
deadlock
9
Eliminate Competition for
Resources?
 If running A to completion
A
S
and then running B, there
will be no deadlock
R
B
 Generalize this idea for all
processes?
 Is it a good idea to develop Previous example
a CPU scheduling algorithm
that causes no deadlock?
10
Strategies
 Ignore the problem
 It is user’s fault
 Detection and recovery
 Fix the problem afterwards
 Dynamic avoidance
 Careful allocation
 Prevention
 Negate one of the four conditions
11
Detection and Recovery
 Detection
 Scan resource graph
 Detect cycles
 Recovery (difficult)
 Kill process/threads (can you always do this?)
 Roll back actions of deadlocked threads
 What about the tape-disk-printer
example?
12
Avoidance
 Banker’s algorithm for a single resource
 Each process has a credit
 Total resources may not satisfy all credits
 Keep track of resources assigned and needed
 Check on each allocation whether it is safe

Safe: there exists a sequence of other states that all
processes can terminate correctly
 Multiple resources
 Read textbook for details
13
Practical Avoidance
 Two-phase locking
 Phase

I:
Try to lock all resources at the beginning
 Phase
II:
If successful, use the resources & release them
 If not, release all resources and start over

 What about the tape-disk-printer
example?
14
Prevention:
Remove Mutual Exclusion
 Some resources are not sharable
 Printer, tape, etc
 Some resources can be made sharable
 Read-only files, memory, etc
 Read/write locks
 Some resources can be made virtual
 Spooling
 Does spooling apply to all non-sharable
resources?
 What about the tape-disk-printer example?
15
Prevention:
Remove Hold and Wait
 Method
 Request for all resources before starting execution
 If all available, it would run
 Otherwise, it will wait
 This is how telephone company prevents
deadlocks
 Problems with this approach?
 What about the tape-disk-printer example?
16
Prevention: No Preemption
 Make scheduler aware of resource allocation
 Method


If a request from a process holding resources cannot be
satisfied, preempt the process and release all resources
Schedule it only if the system satisfies all resources
 Alternative

Preempt the process holding the requested resource
 Copying

Copying to a buffer to release the resource?
 What about the tape-disk-printer example?
17
Prevention: No Circular Wait
 Impose an order of requests for all resources
 Method
 Assign a unique id to each resource
 All resource requests must be in an ascending
order of the ids
 Release resources in a descending order
 Can you prove this method has no circular
wait?
 Does this method work for the tape-diskprinter example?
18
Why Do We Care About This?
 Two possibilities
 Bitten
all the time by this
 Strive to never have it
 Why?
 Fact
of life for some applications
 Faulty programming in others
19
Parallel Scientific Applications
 Really expensive machines
 Overhead counts
 Parallel programs, shared data
 Assumption of smart programmers
 Deadlock detection support is wasted
 Correct programs don’t use it
 Incorrect programs don’t survive
20
Data Access in Scientific Apps
 Lots of small accesses
 Locks often released quickly
 Structured data
 Directed
acyclic graphs, trees, etc
 Predictable patterns of access
Result: deadlock avoidance schemes
21
Databases: Insanely Profitable
 Large amount of shared data
 Lots of accesses to it
 Uncoordinated accesses
 Often no predictability
 Data-dependent program flow
 End-users had different concerns
 Result: good deadlock mechanisms needed
22
Concept of Transactions
Simplified description
 Preserves invariants
 All-or-nothing behavior
 Start/end declared
 No permanent modifications until end
 Restart capabilities assumed
23