CSE Operating Systems

Transcription

1 CSE Operating Systems Notes for Lecture 9-10/7/04 Matt Blaze (some examples by Insup Lee) Our deadlock toolkit (so far) Approach 1: Ignore problem Approach 2: Prevention 2a: Exhaustive Search of Possible States 2b: Ad Hoc Genius 2c: New! Two-Phase Locking 2d: New! Hierarchical Allocation Approach 3: Detection and Recovery 3a: Ad Hoc Genius 3b: New! Cycle Detection (with recovery) Now: Approach 4: Deadlock Avoidance

2 Approach 4: Deadlock Avoidance (a new approach) Remember Deadlock Detection? Example 1: Is this a deadlock? P1 has R2 and R3, and is requesting R1 P2 has R4 and is requesting R3 P3 has R1 and is requesting R4 This example was pretty easy: just notice the cycle in the RAG Example 2: Is this a deadlock? P1 has R2, and is requesting R1 and R3 P2 has R4 and is requesting R3 P3 has R1 and is requesting R4 This example wasn t so easy (depends on the scheduler s handling of P1 vs. P2 for R3)

3 Avoiding Deadlock vs. Preventing Deadlock Deadlock prevention depends on designing the system to deny at least one of the preconditions for deadlock can t be deadlock no matter what, e.g., the scheduler does Another approach, called deadlock avoidance, attempts to allocate resources (at runtime) in a way that distinguishes between safe and unsafe states stay safe and you won t have a deadlock Safe States and Deadlock Environment: Multiple resources requested at the same time some resources have multiple instances assumes processes state requirements in advance system free to make choices at runtime about which resources to allocate (and who to unblock when) Safe states result from making these choices conservatively never select an allocation that could result in deadlock

4 Banker s (Dijkstra s) Algorithm Environment: n process P1,. Pn and m resources R1. Rm Every process declares (in advance) its claim---the maximum number of resources it will ever need Sum of claims of all processes could exceed total number of resources To avoid deadlocks, OS maintains the allocation state Current allocation matrix C: C[i,j] is the number of instances of resource Rj currently held by process Pi Claims matrix M: M[i,j] is the maximum number of instances of Rj that process Pi will ever request Availability vector A: A[j] is the number of instances of Rj currently free. Suppose process Pi requests certain number resources. Let Req be the request vector (Req[j] is number of requested instances of Rj) Valid request if Req <= M[i]-C[i] (i.e. it should be in accordance with claim) If Req <= A, then it is possible for OS to grant the request Avoidance strategy: Deny the request if the resulting state will be unsafe Safe states An allocation state is safe if there is an ordering of processes, a safe sequence, such that: the first process can finish for sure there are enough unallocated resources to satisfy all of its claim If the first process releases its currently held resources, the second process can finish for sure (even if it asks all its claim) and so on. The state is safe because OS can definitely avoid deadlock by blocking any new processes, or any new requests, until all the current processes have finished in the safe order

5 Example (One resource class only) total resources: 12 unallocated: 2 process holding max claims A 4 6 B 4 11 C 2 7 safe sequence: A,C,B Example (One resource class only) total resources: 12 unallocated: 2 process holding max claims A 4 6 B 4 11 C 2 9 safe sequence: none!

6 Banker s algorithm Maintain claims M, current allocation C and current availability A Suppose process Pi requests Req such that Req <= A and Req+C[i] <= M[i] Consider the state resulting from granting this request (i.e. by adding Req to C[i] and subtracting Req from A). Check if the new state is a safe state. If so, grant the request, else deny it. Checking Safety How do we check if an allocation state is safe? Current allocation matrix C Maximum claims matrix M Availability vector A Same as running a deadlock detection algorithm assuming that every process has requested maximum possible resources Choose Requests Matrix R to be M C, and see if the state is deadlocked (is there an order in which all of these requests can be satisfied).

7 Variations on the Banker s Algorithm Multiple resource types just run it for each resource increased and decreased claims at runtime Is Deadlock Avoidance ever practical? Requires that processes state their requirements up front like a credit line But general processes rarely do that Useful mainly in specialized applications that deal with a few classes of inter-changable resources resource allocation among cooperating processes OS services like memory allocation

8 Evaluating our deadlock toolkit Approach 1: Ignore Approach 2: Prevention System design rules 2a: Exhaustive Search of Possible States 2b: Ad Hoc Genius 2c: New! Two-Phase Locking inefficient (spin locks) 2d: New! Hierarchical Allocation maybe, if you can find global ordering Approach 3: Detection and Recovery Runtime techniques 3a: Ad Hoc Genius 3b: New! Cycle Detection (with recovery) OK, but then what? need safe rollback mechanism Approach 4: Deadlock Avoidance runtime techniques 4a: New! Dijkstra s Banker s Algorithm not generally useful, but OK for specialized applications & OS services OK, what do we do? Which tools are best? Deadlock prevention via hierarchical allocation seems in some sense best guarantees that a deadlock can never occur as long as rules are followed no other system support required But there s a significant limitation: all we have is a set of rules for writing programs, not a way to test an arbitrary system for deadlocks in fact, that would be provably impossible! remember the halting problem same reason we don t have SJF schedulers

9 Approach 1 (denial) looking better Most general computing systems don t do deadlock prevention or avoidance as a system service instead, they leave it to applications that need it to fend for themselves avoidance and recovery techniques can be done by directly by applications that require it Deadlock is an issue to the OS designer mainly for managing resources in the OS deadlocks in the OS are very disruptive What about starvation? Even if a system is deadlock-free, we still might have starvation, where some process never gets service mechanisms like semaphores and schedulers don t usually make guarantees about who gets service in what order In practice, we avoid starvation in two ways: fair schedules based on FCFS queues random system behavior to perturb bad cycles No guarantees, but often works in practice