Deadlock

1. Deadlock CS 537 - Introduction to Operating Systems

2. Defining Deadlock • Deadlock is a situation where 2 or more processes are unable to proceed because they are waiting for shared resources. • Three necessary conditions for deadlock • able to hold more than one resource at a time • unwilling to give up resources • cycle • Break any one of these three conditions and deadlock is avoided

3. Example • Imagine 4 cars at an intersection 1 0 2 3

4. Example • Lanes are resources. • Deadlock has occurred because • each car is holding 2 resources (lanes) • none of the cars is willing to backup • car 0 waits for car 1 which waits for car 2 which waits for car 3 which waits for car 0 • this is a cycle • If any ONE of the above conditions can be broken, deadlock would be broken

5. System Resource-Allocation Graph • Tool for detecting deadlock • Shows which process is waiting for which resource • called a request edge • Shows which process is holding which resource • called an assignment edge

6. System Resource-Allocation Graph R0 R1 P0 P1 P2 R2 Request Edges Assignment Edges R0 --> P0 R1 --> P1 R2 --> P0 R2 --> P1 P1 --> R0 P2 --> R1

7. Dealing with Deadlock • Three ways to deal with deadlock • never allow it to occur • allow it to occur, detect it, and break it • ignore it • this is the most common solution • requires programmers to write programs that don’t allow deadlock to occur

8. Not Allowing Deadlock to Occur • Prevent processes from holding multiple resources • not very realistic • hard (or impossible) to get anything done if not allowed to hold more than one resource • could provide multiple copies of resources • not very economical • some resources can’t be duplicated (semaphore)

9. Not Allowing Deadlock to Occur • Preempt Processes • if process can’t get a resource, give up what it has • either all at once • OR as other processes request what it has • Who gets preempted? • Can lead to severe starvation • If resource is easily saved and restored, this is may be okay • CPU, memory image

10. Not Allowing Deadlock to Occur • Don’t allow cycles to happen • Force requests in specific order • for example, must requests resources in ascending order • Process A may have to wait for B, but B will never have to wait for A • Must know in advance what resources are going to be used

11. Not Allowing Deadlock to Occur • Force processes to declare needed resources • process must do this before starting • OS examines each processes requests and decides if a deadlock could occur • don’t allocate resource • conservative approach • Again, process must know what it wants before hand

12. Detecting Deadlock • There are available resources • avail[r] = # of resources not allocated • r is number of different resources in system • There exists a set of requests for resources • req[p][r] = # of units of resource r requested by process p • There exists a set of resources allocated to a specific process • alloc[p][r] = # of units of resource r currently held by process p

13. Detecting Deadlock • 2 Systems - one deadlocked and one not R0 R1 R0 R1 P0 P0 P1 P1 P2 P2 R2 R2 1) Deadlock Free System 2) Deadlocked System

14. Detecting Deadlock • Basic idea • examine the system for cycles • find any job that can satisfy all of its requests • assume it finishes and give its resources back to the system • remove the process’s node from the graph • repeat the process until • no nodes left - no deadlock • can’t remove any more nodes - deadlocked

15. Detecting Deadlock • Algorithm boolean deadlock(int [][] req) { boolean [] done = new boolean[N]; // N = # of processes initialize done to all false for(int p=0; p<N; p++) { find p such that (!done[p] && req[p] <= avail) if (p is not found) return true; // DEADLOCK else { avail += alloc[p]; done[p] = true; } } return false; // NO deadlock }

16. Example of Algorithm • Examine the following system r = 3; N = 5 avail[r] = {0, 0, 1 } req[n][r] = { (0, 0, 1), (1, 0, 0), (0, 0, 0) } alloc[n][r] = { (2, 0, 0), (0, 0, 2), (1, 1, 3) } Now trace through algorithm. Final solution: No deadlock. R0 R1 P0 P1 P2 R2

17. Bankers Algorithm • This is a method for detecting if allocating a could lead to deadlock • Don’t allow allocation if deadlock could occur • conservative approach • requires processes declare up front what they need • this is a processes credit

18. Bankers Algorithm boolean bankers (int p, int [] breq) { // do some error checking - make sure not exceeding credit, etc. avail -= breq; credit[p] -= breq; alloc[p] += breq; if( safe() ) return true; else restore avail, credit, and alloc to original values return false; } boolean safe() { return !deadlock(credit); }

19. Current Allocation Initial Credit Bankers Algorithm • Consider the following set of credits, allocations, and availabilities units of resources = initial avail[r] = { 8, 7, 7 } avail[r] = { 4, 2, 3 } current credits for each process

20. Bankers Algorithm • Consider the following requests: • P3 requests: (2, 2, 2) • overdrawn - denied • P5 requests: (5, 0, 0) • only 4 available - must wait • P3 requests: (3, 1, 0) • run algorithm (assume adjusted credits become requests for deadlock detection) • notice this is conservative • in this case, request can be granted

21. Deadlock Recover • first, must be able to detect deadlock • use deadlock method described earlier • running time is O(n2 m) • this can lead to poor performance if done on every request - processes requests resources frequently • run deadlock algorithm at set intervals • how often is deadlock likely to occur? • how many processes will be affected?

22. Deadlock Recovery • So what to do if deadlock is discovered? • OS can start killing processes • OS can revoke resources from processes • Both of the above solutions will eventually end a deadlock • which processes to kill? • which resources to revoke?

23. Process Termination • Two solutions • kill all deadlocked processes • very costly (work is lost) • kill one process at a time until deadlock is broken • high overhead (must re-run deadlock algorithm after each killing) • still have cost of lost work • which process to kill?

24. Process Termination • Which process to kill? • must have some type of cost analysis • kill lowest priority process • kill youngest process (least amount of work done) • kill process with most resources (gives greatest chance of ending deadlock) • kill process with most outstanding resource requests (removes the most request edges from graph) • Will have to restart killed processes later • avoid starvation

25. Resource Preemption • Let processes stay alive but revoke some of their resources • Again, must select process to preempt • take resources from biggest “hog” • take resources from youngest

26. Resource Preemption • What to do with preempted process? • rollback to safe state • difficult to determine what was safe state • must keep extra state around • example: semaphore • if preempt the semaphore from some process, it must be rolled back to way it was before entering critical section • otherwise there is an inconsistant state • Beware of starvation

27. Dining Philosophers • Philosophers sitting around a dining table • Philosophers only eat and think • Need two forks to eat • Exactly as many forks as philosophers • Before eating, a philosopher must pick up the fork to his right and left • When done eating, each philosopher sets down both forks and goes back to thinking

28. P 0 P 1 F 1 F 0 F 2 P 5 P 2 F 5 F 3 F 4 P 4 P 3 Dining Philosophers

29. Dining Philosophers • Only one philosopher can hold a fork at a time • One major problem • what if all philosophers decide to eat at once? • if they all pick up the right fork first, none of them can get the second fork to eat • deadlock

30. Philosopher Deadlock Solutions • Make every even numbered philosopher pick up the right fork first and every odd numbered philosopher pick up the left fork first • Don’t let them all eat at once • a philosopher has to enter a monitor to eat • can only get into the monitor if no one else in it • only one philosopher is allowed to eat at a time

31. Philosopher Deadlock Solution monitor diningPhilosopher { int [] state = new int[5]; static final int THINKING = 0; static final int HUNGRY = 1; static final int EATING = 2; condition [] self = new condition[5]; public diningPhilosphers { for(int i=0; i<5; i++) state[i] = THINKING; } public pickup(int i) { state[i] = HUNGRY; test(i); if (state[i] != EATING) self[i].wait; } public putDown(int i) { state[i] = THINKING; test((i+5) % 6); test((i+1) % 6); } private test(int i) { if( (state[(i + 5) % 6] != EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 6] != EATING) ) { state[i] = EATING; self[i].signal; } } }