CS 346 – Chapter 7

1. CS 346 – Chapter 7 • Deadlock • Properties • Analysis: directed graph • Handle • Prevent • Avoid • Safe states and the Banker’s algorithm • Detect • Recover

2. Origins of deadlock • System contains resources • Process compete for resources: • request, acquire / use, release • Deadlock occurs on a set of processes when each one is waiting for some event (e.g. the release of a resource) that can only be triggered by another deadlocked process. • e.g. P1 possesses the keyboard, and P2 has the printer. P1 requests the printer and goes to sleep waiting. P2 requests the keyboard and goes to sleep waiting. • Sometimes hard to detect because it may depend on the order in which resources are requested/allocated

3. Necessary conditions 4 conditions to detect for deadlock: • Mutual exclusion – when a resource is held, the process has exclusive access to it • Hold and wait – processes each hold 1+ resource while seeking more • No preemption – a process will not release a resource unless it’s finished using it • Circular wait • The first 3 conditions are routine, so it’s the circular wait that is usually the big problem. • Model using a directed graph, and look for cycle

4. Directed graph • A resource allocation graph is a formal way to show we have deadlock • Vertices include processes and resources • Directed edges • (P  R) means that process requests a resource • (R  P) means that resource is allocated to process • If a resource has multiple instances • Multiple processes may request or be allocated the resource • Intuitive, but make sure you don’t over-allocate • e.g. Figure 7.2: Resource R2 has 2 instances which are both allocated. But process P3 also wants some of R2. The “out” degree of R2 is 2 and “in” degree is 1.

5. Examples • R2 has 2 instances. • We can have these edges: P1  R2, P2  R2, P3  R2. • What does this situation mean? What should happen next? • Suppose R1 and R2 have 1 instance each. • Edges: R1  P1, R2  P2, P1  R2 • Describe this situation. • Now, add this edge: P2  R1 • Deadlock? • Fortunately, not all cycles imply a deadlock. • There may be sufficient instances to honor request • Fig 7.3 shows a cycle. P1 waits for R1 and P3 waits for R2. But either of these 2 resources can be released by processes that are not in the cycle…. as long as they don’t run forever.

6. How OS handles • Ostrich method– pretend it will never happen. Ignore the issue. Let the programmer worry about it. • Good idea if deadlock is rare. • Dynamically prevent deadlockfrom ever occurring • Allow up to 3 of the 4 necessary conditions to occur. • Prevent certain requests from being made. • A priori avoidance • Require advance warning about requests, so that deadlock can be avoided. • Some requests are delayed • Detection • Allow conditions that create deadlock, and deal with it as it occurs. • Must be able to detect!

7. Prevention • “An ounce of prevention is worth a pound of cure”: Benjamin Franklin • Take a look at each of the 4 necessary conditions. Don’t allow it to be the 4th nail in the coffin. • Mutual exclusion • Not much we can do here. Some resources must be exclusive. • Which resources are sharable? • Hold & wait • Could require a process to make all its requests at the beginning of its execution. • How does this help? • Resource utilization; and starvation?

8. Prevention (2) 3. No resource preemption • Well, we do want to allow some preemption • If you make a resource request that can’t be fulfilled at the moment, OS can require you to release everything you have. (release = preempting the resource) • If you make a resource request, and its held by a sleeping process, OS can let you steal it for a while. 4. Circular wait • System ensures the request doesn’t complete a cycle • Total ordering technique: Assign a whole number to each resource. Process must request resources in numerical order, or at least not request a lowered # resource when it holds a higher one. • Fig. 7.2: P3 has resource #3 but also requests #2. OS could reject this request.

9. Avoidance • We need a priori information to avoid future deadlock. • What information? We could require processes to declare up front the maximum # of resources of each type it will ever need. • During execution: let’s define a resource-allocation state, telling us: • # of resources available (static) • Maximum needs of each process (static) • # allocated to each process (dynamic)

10. Safe state • To be in a safe state, there must exist a safe sequence. • A safe sequence is a list of processes [ P1, P2, … Pn ] • for each P_i, we can satisfy P_i’s requests given whatever resources are currently available or currently held by the processes numbered lower than i (i.e. Pj where j < i) by letting them finish. • For example, all of P2’s possible requests can be met by either what is currently available or by what is held by P1. • If P3 needs a resource held by P2, can wait until P2 done, etc. • Safe state =  a safe sequence including all processes. • Deadlock occurs only in an unsafe state. • The system needs to examine each request and ensure that if the allocation will preserve the safe state.

11. Example • Suppose we have 12 instances of some resource. • 3 processes have these a priori known needs • We need to find some safe sequence of all 3 processes • At present, 12 – (5 + 2 + 2) = 3 instances available. • Is [ 1, 2, 3 ] a safe sequence?

12. Banker’s algorithm • General enough to handle multiple instances • Principles • No customer can borrow more money than is in the bank • All customers given maximum credit limit at outset • Can’t go over your limit! • Sum of all loans never exceeds bank’s capital. • Good news: customers’ aggregate credit limit may be higher than bank’s assets • Safe state: Bank has enough “money” to service request of 1 customer. • Algorithm: satisfy a request only if you stay safe • Identify which job has smallest remaining requests, and make sure we always have enough dough

13. Example • Consider 10 devices of the same type • Processes 1-3 need up to 4, 5, 8 of these devices, respectively • Are these states safe?

14. Handling deadlock • Continually employ a detection algorithm • Search for cycle • Can do it occasionally • When deadlock detected, perform recovery • Recover by killing • Kill 1 process at a time until deadlock cycle gone • Kill which process? Consider: priority, how many resources it has, how close it is to completion. • Recover by resource preemption • Need to restart that job in near future. • Possibility for starvation if the same process is selected over and over.

15. Detection algorithm • Start with allocation graph, and “reduce it” While no changes do: • Find a process using a resource & not waiting for one. Remove edge: process will eventually finish. • Can now re-allocate this resource to another process, if needed. • Also can perform other resource allocations for resources not fully allocated. • If there are any edges left, we have deadlock.

16. Example • 3 processes & 3 resources • Edges: • (R1  P1) • (P1  R2) • (R2  P2) • (P2  R3) • (R3  P3) • Can this graph be reduced to the point that it has no edges?