Deadlocks

Vivek Pai / Kai Li

Princeton University

2

Bankgedanken

How much money do banks keep?

What is a bank run?

How do you handle it?

3

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

4

Let’s Talk About Deadlockswish I’d read

Chapter 3

5

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

6

Resource Allocation Graph

Process A is holding resource R

Process B requests resource S

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 R

B S

A S

BR

7

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

tape disk printer

A

B

8

What Causes Deadlocks?

Guns don’t cause deadlocks – people do

9

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

10

Eliminate Competition for Resources? If running A to completion

and then running B, there will be no deadlock

Generalize this idea for all processes?

Is it a good idea to develop a CPU scheduling algorithm that causes no deadlock?

A S

BR

Previous example

11

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

12

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?

13

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

14

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?

15

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?

16

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?

17

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?

18

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-disk-printer example?

19

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

20

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

21

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

22

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

23

Concept of Transactions

Simplified description Preserves invariants All-or-nothing behavior Start/end declared No permanent modifications until end Restart capabilities assumed