Deadlocks Vivek Pai Kai Li Princeton University Bankgedanken

Deadlocks Vivek Pai / Kai Li Princeton University

Bankgedanken n How much money do banks keep? n What is a bank run? n How do you handle it? 2

Mechanics n Dec 10 class canceled n Readings – sketchy from here on n Next project – VM n Wednesday night midterm discussion n 8: 30 pm, room 105 n Rough “grades” will be sent out soon 3

Let’s Talk About Deadlocks wish I’d read Chapter 3 4

Definitions n Resources n Preemptable (can be taken away): CPU n Non-preemptable (cannot be taken away): Disk, files, mutex, . . . n Starvation n Processes/threads wait indefinitely n Typical way to use a resource n Request n Use n Release 5

Resource Allocation Graph n Process A is holding resource R A R n Process B requests resource S B n A cycle in the resource allocation graph means that there is deadlock n 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 n A utility program n copies a file from a tape to disk n prints the file to a printer n Resources n tape n disk n printer n A deadlock A tape disk printer B 7

What Causes Deadlocks? Guns don’t cause deadlocks – people do 8

Conditions for Deadlock n Mutual exclusion condition n Each resource is assigned to exactly one process n Hold and Wait n Multiple independent requests n No preemption n Resources cannot be taken away n Circular chain of requests Note: eliminating any condition eliminates deadlock 9

Eliminate Competition for Resources? n If running A to completion A S and then running B, there will be no deadlock R B n Generalize this idea for all processes? n Is it a good idea to develop Previous example a CPU scheduling algorithm that causes no deadlock? 10

Strategies n Ignore the problem n It is user’s fault n Detection and recovery n Fix the problem afterwards n Dynamic avoidance n Careful allocation n Prevention n Negate one of the four conditions 11

Detection and Recovery n Detection n Scan resource graph n Detect cycles n Recovery (difficult) n Kill process/threads (can you always do this? ) n Roll back actions of deadlocked threads n What about the tape-disk-printer example? 12

Avoidance n Banker’s algorithm for a single resource n Each process has a credit n Total resources may not satisfy all credits n Keep track of resources assigned and needed n Check on each allocation whether it is safe n Safe: there exists a sequence of other states that all processes can terminate correctly n Multiple resources n Read textbook for details 13

Practical Avoidance n Two-phase locking n Phase I: n Try to lock all resources at the beginning n Phase II: n If successful, use the resources & release them n If not, release all resources and start over n What about the tape-disk-printer example? 14

Prevention: Remove Mutual Exclusion n Some resources are not sharable n Printer, tape, etc n Some resources can be made sharable n Read-only files, memory, etc n Read/write locks n Some resources can be made virtual n Spooling n Does spooling apply to all non-sharable resources? n What about the tape-disk-printer example? 15

Prevention: Remove Hold and Wait n Method n Request for all resources before starting execution n If all available, it would run n Otherwise, it will wait n This is how telephone company prevents deadlocks n Problems with this approach? n What about the tape-disk-printer example? 16

Prevention: No Preemption n Make scheduler aware of resource allocation n Method If a request from a process holding resources cannot be satisfied, preempt the process and release all resources n Schedule it only if the system satisfies all resources n n Alternative n Preempt the process holding the requested resource n Copying to a buffer to release the resource? n What about the tape-disk-printer example? 17

Prevention: No Circular Wait n Impose an order of requests for all resources n Method n Assign a unique id to each resource n All resource requests must be in an ascending order of the ids n Release resources in a descending order n Can you prove this method has no circular wait? n Does this method work for the tape-diskprinter example? 18

Why Do We Care About This? n Two possibilities n Bitten all the time by this n Strive to never have it n Why? n Fact of life for some applications n Faulty programming in others 19

Parallel Scientific Applications n Really expensive machines n Overhead counts n Parallel programs, shared data n Assumption of smart programmers n Deadlock detection support is wasted n Correct programs don’t use it n Incorrect programs don’t survive 20

Data Access in Scientific Apps n Lots of small accesses n Locks often released quickly n Structured data n Directed acyclic graphs, trees, etc n Predictable patterns of access Result: deadlock avoidance schemes 21

Databases: Insanely Profitable n Large amount of shared data n Lots of accesses to it n Uncoordinated accesses n Often no predictability n Data-dependent program flow n End-users had different concerns n Result: good deadlock mechanisms needed 22

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