Deadlock Wednesday, October 13, :08 PM

Transcription

1 Deadlock Page 1 Deadlock Wednesday, October 13, :08 PM Deadlock Other side of spectrum (from race conditions) Common forms Circular dependencies. Resource saturation. All symptoms of roughly the same condition Too many requirements Requirements depend upon one another in a "circular" way.

2 Circular dependencies Deadlock Page 2

3 Circular dependency example Two resources: A and B Two programs: P and Q P: Lock A Lock B Do something Release A Release B Q: Lock B Lock A Do something Release B Release A Deadlock Page 3

4 Deadlock Page 4 Analysis If "P:Lock A" and "Q:Lock B" happen before "P: Lock B" and "Q: Lock A", then P waits forever for "Lock B" (held by Q) Q waits forever for "Lock A" (held by P)

5 Deadlock Page 5 More than two processes Processes P1, P2,... Resources R1, R2, P1: P3: Lock R1 Lock R3 Lock R2 Lock R4 P2: P4: Lock R2 Lock R4 Lock R3 Lock R1

6 Resource starvation Special case of circular dependency Limited resources Demand exceeds supply Incremental allocation Deadlock Page 6

7 Limited number of array elements. Process 1 requests more than half Process 2 requests more than half Result: both processes wait forever Key to deadlock: incremental allocation Deadlock Page 7

8 Deadlock Page 8 Example of resource lock: Only 6 memory elements available Process 1 and 2: int *a[5]; for (i=0; i<5; i++) a[i]=getmem();

9 Deadlock Page 9 Resource Allocation Graphs Wednesday, October 13, :03 PM One aid to understanding: resource allocation graph

10 Circular dependency Deadlock Page 10

11 No deadlock Deadlock Page 11

12 Deadlock Page 12 Coping with deadlock Wednesday, October 13, :27 PM Coping with deadlock Prevention through programming practice Prevention through OS features Passive defenses: detecting and breaking locks Controversy: Bug or feature? One opinion: a deadlock is always due to a program bug Contrary opinion: preventing deadlock is the job of the operating system.

13 Deadlock Page 13 Key to deadlock prevention: atomicity of allocation Request resources "all at once" Avoid resource allocation "races" Deep reason behind capability to perform several semaphore operations simultaneously

14 Deadlock Page 14 Process P: Lock A,B Do something Unlock A,B Process Q: Lock B.A Do something Unlock B,A

15 Limiting resource allocation deadlock Process P and Q: request (a,5); // do something release (a,5) ; Deadlock Page 15

16 Deadlock Page 16 OS Deadlock prevention methods Provide atomic multiple-resource locks Prioritize locks, so that circular dependencies cannot occur. Detect and break deadlocks proactively

17 Deadlock Page 17 Lock prioritization Wednesday, October 13, :00 PM Lock prioritization Give each lock a priority Require locking in order of priority If attempt is made to access out of order, Break lower priority locks Relock in priority order Key idea: Whenever a lock request is made, consider all of the locks we hold. at end of request, should hold all of them. allow releases in the middle of the request.

18 Deadlock Page 18 This is difficult to understand: Suppose A B; A must be locked first P: Lock A; Lock B; do something; Unlock A; Unlock B; Q: Lock B; Lock A; do something; Unlock B; Unlock A;

19 Deadlock Page 19 Implementation semaphores are a kernel table refer to by number. number is offset into table. Low-numbered semaphore wins. arbitrary. unknown to process. if we unlock while waiting for higher-priority locks (lower-numbered binary semaphores) deadlock cannot occur.

20 Deadlock Page 20 Controversy: this takes time Reason: orthogonality. if R1> S1 > R2 > 1, lock R2 followed by R1: lock(r2) unlock(r2) lock(r1) lock (R2)

21 Deadlock Page 21 Example: file locking R1: file lock. R2: some other thing, e.g., tape Code lock(r2); FILE *F = fopen("foo","r"); lock(r1); copy contents of F onto /dev/mt0 unlock(r2) unlock(r1) Code2: lock(r2); FILE *g = fopen("foo","r"); fgets(buf,1024,g); unlock(r2); OOPS! Code2 (unknown to code1) reads first line of file out from under Code1, so contents of tape are 2nd line onward!

22 Deadlock Page 22

23 Deadlock Page 23 Priority locking caveats Only works for single resources (not resources having multiple instances) All priorities must be different or ties ensue, deadlock possible. If two processes contend, and one locks in order while the other one does not, then the one that locks in order goes first. If two processes contend in order, then first one wins.

24 Deadlock Page 24 Proofs of validity Wednesday, October 12, :37 PM In dealing with locking algorithms, Race conditions are common. Failure modes are rare. Software testing is not enough. Must learn to prove that algorithms work. Proof means that there is no possibility of failure. Stronger than testing. Depends, however, upon assumptions. Kinds of proof relevant to operating systems: Enumeration: consider all possibilities, prove that same thing happens in all cases. Induction: Basis step: some simple version is true. Inductive step: assume true for n, prove true for n+1. Example: Demonstrate conclusively that lock prioritization makes sequences of binary locks effectively atomic. Binary lock prioritization algorithm: Number possible locks, system wide, from 1 to n. When requesting lock number k, release all held locks with numbers m>k (lower priority). lock k. lock other locks in increasing order (decreasing priority). Step 1: understand what happens when all processes request locks in order Lock prioritization algorithm does not change anything. No deadlock is possible.

25 Deadlock Page 25 Lemma 1: For two processes, both of whom request n binary locks in priority order, perform a computation that completes, and release locks in any order, one process always runs to completion. Hence both processes complete and deadlock is not possible. Proof: Induction on number of locks n. Basic: n=1 works fine. Assume true for n, consider n+1 locks. By the inductive hypothesis, one of the two processes manages to achieve all n locks first. Thus it must be the winner in getting the n+1st lock. Thus it wins and completes. Q.E.D. Lemma 2: For k processes, all of whom request locks in priority order, and which complete and release all requested locks, no deadlock is possible. Proof: Induction on number of processes k. If k=1, the lemma is trivially true. Assume true for k, consider k+1 processes. By inductive hypothesis, for k processes, one must win the race and acquire all n locks. Consider the relationship between this "winner" process and the additional process numbered k+ 1. By lemma 2, one of these two processes must "win" the simple race to lock all locks. Thus it is the overall winner and the lemma is true. Q.E.D.

26 Deadlock Page 26 Step 2: understand what happens when requests are made out of order. Lemma 3: Suppose that a process requests m locks in any order via the lock priority algorithm. The result of this is that the operating system actually requests the locks in priority order, with some locking and unlocking before the correct order is achieved. Proof by induction: Vocabulary: "lock request": when the application asks for a lock. "lock action": when the OS asks for a lock. For one lock request, the process is trivially true. Now assume that for m lock requests, the lemma is true. Consider the case of m+1 lock requests, and consider what happens during the last lock request in sequence. Q.E.D. If the request is for the lowest-priority lock, the lemma is true, because by the inductive hypothesis the first m are locked in order. If it is not the lowest priority lock, according to the inductive hypothesis, the first m locks occur in priority order. According to the algorithm, all locks with lower priority than the last are unlocked, and then all are locked in order. Since lower-number locks are already made in order, and higher-number locks are made in order by the algorithm, the whole sequence is done in order.

27 Deadlock Page 27 Key issue: no lock that occurs out of order stays locked. Theorem: Lock prioritization is deadlock-free. Proof: Suppose we have k processes and n locks. By lemma 3, the algorithm results in each process trying to lock resources in order, with some other lock attempts out of order that are released during the next lock request. The actual requests made by the operating system are thus (other than minor excursions out of order) in priority order, and by Lemma 2, one process always wins the race and completes. By induction on k, all processes complete. Q.E.D.