Deadlocks. Frédéric Haziza Spring Department of Computer Systems Uppsala University

Transcription

1 Deadlocks Frédéric Haziza Department of Computer Systems Uppsala University Spring 2008

2 Outline 1 Quick recall on Synchronisation 2 Characterizing Deadlocks 3 Handling Deadlocks 2 OSKomp 08 Deadlocks

3 Synchronisation Communication Synchronisation Synchronisation Mutual Exclusion Condition synchronisation Example (Mutual Exclusion) Whenever 2 processes need to take runs accessing shared objects Example (Condition synchronisation) Whenever one process needs to wait for another 4 OSKomp 08 Deadlocks

4 Atomicity Bank account example Balance b = 0 sek. Person A does a deposit of 100 sek. Person B does a deposit of 200 sek Balance should be 300 sek. A Balance b B 0 load R 4, b load R 2, b 0 add R 2,#100 store b, R add R 4,# store b, R 4 Solution: Synchronisation (Locks,Semaphores,Monitors,Retry loops,...) 5 OSKomp 08 Deadlocks

5 Atomicity Another example sum:=0 while (sum < N) while (sum < N) sum:=sum+1 while (sum < N) sum:=sum+1 while (sum < N) sum:=sum+1 sum:=sum+1 How many additions? Anything between N and N*4 6 OSKomp 08 Deadlocks print(sum) What is printed? Anything between N and N+3

6 Critical Section CO [Process i = 1 to n] { while (true) { LOCK(resource); } } Assumption Do critical section work; UNLOCK(resource); Do NON-critical section work; A process may only terminate in its NON-critical section 7 OSKomp 08 Deadlocks

7 The programmer s nightmare begins The programmer must implement correct synchronization! Example (lock S and Q) P 1 P 2 lock(s) lock(q) lock(q) lock(s) unlock(q) unlock(s) unlock(s) unlock(q) Leads to deadlock: Both P 1 and P 2 are waiting for each other Additionally, bad implementation can lead to starvation. 8 OSKomp 08 Deadlocks

8 Say stop at entry section... The main issue is How do we make a thread wait? A solution: Busy waiting Check repeatedly a condition until it becomes true. Another solution: Blocking Waiting threads are de-scheduled High overhead Allows processor to do other things Hybrid methods: Busy-wait a while, then block 9 OSKomp 08 Deadlocks

9 Challenge Task Design the LOCK and UNLOCK routines. Ensuring: Mutual Exclusion No deadlocks No unnecessary delays Eventual Entry 10 OSKomp 08 Deadlocks

10 Requirements for a solution Mutual exclusion Only one process at a time in its CS Progress If no process is in its CS and some processes want to enter their CS, only those processes which are not in their remainder section can influence the decision on which process will enter its CS next. This decision can not be postponed indefinitely Bounded waiting When one process has requested to enter its CS, there is a limit on the number of times other processes can enter their CS before the request is granted. 11 OSKomp 08 Deadlocks

11 How to? < await(!lock) and then lock = true; > Read-Modify-Write atomic primitives Test and Set (TAS): Value at Mem[lock_addr] loaded in a specified register. Constant 1 atomically stored into Mem[lock_addr] Swap: Atomically swaps the value of REG with Mem[lock_addr] Compare and Swap (CAS): Swaps if Mem[lock_addr]==REG2 Fetch and Add (FA): Increments a value by a given constant and returns the old value 12 OSKomp 08 Deadlocks

12 Spin Lock bool TAS(bool lock) { < bool initial = lock; Save the initial value lock = true; Set lock return initial; > Return initial value } lock(lock_variable) { while(tas(lock_variable)==true){}; } Bang on the lock until free unlock(lock_variable) { lock_variable:=false; } Reset to the initial value 13 OSKomp 08 Deadlocks

13 Test and Test and Set lock(lock_variable) { while(tas(lock_variable)==true){}; } } lock(lock_variable) { More optimistic solution while (true) { if(tas(lock_variable)==false) break; } Bang on the lock once while(lock_variable==true){}; 14 OSKomp 08 Deadlocks

14 Tie Breaker Petersson s algorithm Remember who had the lock latest! bool in1 = false, in2 = false; int last = 1; Process 1 while (true) { in1=true, last = 1; while(in2 and last==1){}; Do critical section work in1=false; Do NON-critical section work } Process 2 while (true) { in2=true, last = 2; while(in1 and last==2){}; Do critical section work in2=false; Do NON-critical section work } 15 OSKomp 08 Deadlocks

15 Ticket-based lock CO [Process i = 1 to n] { while (true) { <turn[i] = number; number = number+1;> < await(turn[i] == number);> Do critical section < next = next+1;> Do NON-critical section } } Fetch and Add (FA) Increments a value by a given constant and returns the old value CO [Process i = 1 to n] { while (true) { turn[i] = FA(number,1); while(turn[i]!= next){}; Do critical section next = next+1; Do NON-critical section } } Can even have a back-off 16 OSKomp 08 Deadlocks

16 Semaphore Shared variable with 2 atomic methods: } P(Semaphore s) { Probeer (try) / Passeren (pass) / Pakken (grab) < wait until c > 0, then c := c-1; > must be atomic once c > 0 is detected } V(Semaphore s) { Verhoog (increase) < c = c + 1; > must be atomic Init(Semaphore s, Integer i){ c := i; } 17 OSKomp 08 Deadlocks

17 Semaphores, what for? Critical section: Mutual exclusion Barriers: Signaling events Producers and Consumers Bounded buffers: Resource counting 18 OSKomp 08 Deadlocks

18 Critical section sem mutex; Init(sem,1); 1 0 while (true) { Process 1 } P(mutex); Critical section V(mutex); NON-Critical section while (true) { Process 2 } P(mutex); Critical section V(mutex); NON-Critical section 19 OSKomp 08 Deadlocks

19 Barriers: Signaling events sem arrive1, arrive2; Init(arrive1,0); Init(arrive2,0); 0 0 Barrier Section A Section B... process 1 in section A V(arrive1); signal arrival P(arrive2); Wait for the other process... process 1 in section B... process 2 in section A V(arrive2); signal arrival P(arrive1); Wait for the other process... process 2 in section B 20 OSKomp 08 Deadlocks

20 Semaphores: Procuders and Consumers put Empty Full 1 0 take Producer Consumer Buffer Split Binary Semaphore Both are binary semaphores 21 OSKomp 08 Deadlocks

21 Bounded buffer: Resource counting put Empty n Full 0 take Producer Consumer Buffer 22 OSKomp 08 Deadlocks

22 Semaphores, what for? Empty Full 1 0 n Critical Section Blocking semaphore Barriers/Signaling Split Binary semaphore Resource Counting 23 OSKomp 08 Deadlocks

23 Dining Philosophers Problem Philopher 1 Philopher 2 Spaghetti Philopher 0 Philopher 3 Philopher 4 sem fork[5] = {1,1,1,1,1} while (true) { Philosopher 0,1,2,3,4 think; P(fork[i]);P(fork[i+1]); eat; V(fork[i]);V(fork[i+1]); } 24 OSKomp 08 Deadlocks

24 Readers/Writers Shared Resource Readers Writer Writer Example of selective mutual exclusion Example of general condition synchronization 25 OSKomp 08 Deadlocks

25 Monitors Skip 26 OSKomp 08 Deadlocks

26 Outline 1 Quick recall on Synchronisation 2 Characterizing Deadlocks Resources Resource Allocation Graph Conditions 3 Handling Deadlocks 27 OSKomp 08 Deadlocks

27 Resources In shared memory systems, synchronisation deals with CPU allocation with respect to...memory! Other types of resources: CPU, disks, tapes, files,...memory. Each resource type may have a different number of instances (example: 2 CPUs, 3 disks, N buffer places...) but instances may or may not be equivalent (e.g. printers on different floors). 28 OSKomp 08 Deadlocks

28 Resources To protect against races, a resource may be 1 requested before use, waiting until it is available. Open file, allocate memory, move to ready queue... 2 used 3 released after use. Close file, deallocate memory, terminate/wait... Deadlock Arises when two or more processes wait for each other, and the only way out is if one releases a resource another is waiting for. 29 OSKomp 08 Deadlocks

29 Resource Allocation Graph A graph a set of vertices υ a set of edges ǫ System Resource Allocation Graph Active Processes P = {P 1, P 2,...,P n } (Circles) Resource Types R = {R 1, R 2,..., R m } (Boxes) Request edges (P i R j ) Assignment edges (R j P i ) Number of instances per resource type 30 OSKomp 08 Deadlocks

30 Deadlocks: Resource Allocation Graph R 1 R 3 P 1 P 2 P 3 Deadlock? No cycle No process is deadlocked If cycle, deadlock may exist R 2 R 4 31 OSKomp 08 Deadlocks

31 Cycle in the Graph? If each resource has ONE instance cycle deadlock Each process involved in the cycle is deadlocked Both necessary and sufficient condition for deadlock If each resource has SEVERAL instance cycle deadlock Necessary but not sufficient condition for deadlock 32 OSKomp 08 Deadlocks

32 RAG example R 1 R 3 P 1 R 1 P 2 R 3 P 3 R 2 P 1 P 2 R 3 P 3 R 2 P 2 P 1 P 2 P 3 R 2 P 1, P 2, P 3 are deadlocked R 4 33 OSKomp 08 Deadlocks

33 RAG example P 2 P 1 R 1 P 3 R 2 P 1 R 1 Not in deadlock state. P 1 R 2 P 3 Important because we then can deal with deadlocks (Apply algorithms, induce choice,...) P 4 p 4 may deallocate R 2 34 OSKomp 08 Deadlocks

34 Conditions Mutual exclusion At least one resource must be nonsharable (only one process can use it) Hold and wait At least one process holds at least one resource and waits for more resources which are held by other processes No preemption Only the process holding a resource can release it. Circular wait A set of processes are waiting for resources held by others in a circular manner < P 0,..., P n > where P i waits for a resource held by P i+1[n]. 35 OSKomp 08 Deadlocks

35 Outline 1 Quick recall on Synchronisation 2 Characterizing Deadlocks 3 Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection Deadlock Recovery 36 OSKomp 08 Deadlocks

36 How do we proceed? 1 Make sure they never occur deadlock prevention (make sure at least one of the conditions above never hold) deadlock avoidance (keeping more information about processes, allocate resources so that deadlocks cannot appear) 2 Deal with them deadlock detection deadlock recovery (work in pair) 3 Ignore them! if they don t appear too often, it s cheaper to restart the system/processes 37 OSKomp 08 Deadlocks

37 Deadlock Prevention Idea : Make sure one of the conditions is never satisfied. Mutual exclusion Difficult, since some resources cannot be shared (e.g. CPU). For some resources it works fine (e.g. read-only files). 38 OSKomp 08 Deadlocks

38 Deadlock Prevention Hold and wait Make sure that when a process requests a resource, it doesn t hold any other resources. allocate all resources before starting difficult to predict, waste of resources (low utilization) allow resource requests only when the process has none in some cases degenerates to the previous (e.g. printing files from two CDs directly after each other). Risk for starvation for "popular" resources. 39 OSKomp 08 Deadlocks

39 Deadlock Prevention No preemption Preempt (force release) allocated resources. Release all If the process holds a resource, requests another, and can t get it immediately, release all its resources (and have it wait for them all) - cf process scheduling! Release when waiting If the requested resources are not available, but allocated by a process which is waiting for some other resource, steal the resource (deallocate from waiting, allocate to requesting) and have the original holder wait for also this resource. Solutions work for some resource types (e.g. CPU, memory - easy to store and reload state) but not for others (e.g. printers!) 40 OSKomp 08 Deadlocks

40 Deadlock Prevention Circular wait Make a total ordering (<) of all resource types, and only allow requests in this order: If a process has R 1 and requests R 2, allow only if R 1 < R 2 (otherwise must deallocate R 1 first). If several instances of the same type are needed, must allocate all together. 41 OSKomp 08 Deadlocks

41 Deadlock Avoidance Deadlock prevention can lead to low resource utilization and reduced throughput. If the system knows which resources will be requested by each process, and in which order, the system can order the requests so that deadlocks can not occur. Yet difficult to describe, we could require extra information, to take better decision. 42 OSKomp 08 Deadlocks

42 Deadlock Avoidance Easiest solution: each process declares the maximum number of each resource type it will need (e.g. put in the PCB). At each request, the system dynamically checks the resource-allocation state to make sure the circular wait condition will not be satisfied if the request is granted. 43 OSKomp 08 Deadlocks

43 Deadlock Avoidance Safe state Algorithm idea preserve a safe state of resource allocations. safe state: if all processes can be given their maximum resource allocation (in some order) and avoid deadlock. The order of allocations is a safe sequence: < P 1, P 2,..., P n > is a safe sequence for the current allocation state if for each P i, its maximum resource requests can be satisfied using its current resources plus the resources held by all P j where j < i. In order to use the resources of P j, P i may have to wait until they terminate, but P i can get its resources! When P i terminates, P i+1 can get its resources, etc. 44 OSKomp 08 Deadlocks

44 Deadlock Avoidance Safe state If there is no safe sequence, the state is unsafe. An unsafe state may lead to deadlock, but doesn t have to. A safe sequence never leads to deadlock. Refined algorithm idea Allow only allocations which lead to a safe state. a process which requests a resource which is available may have to wait! Thus, the resource utilization may be less than optimal - but there will be no deadlocks. Concrete algorithm The Banker s Algorithm (section 7.5.3). Never allocate the cash so customers can t get all they need. 45 OSKomp 08 Deadlocks

45 Deadlock Detection Need both detection and recovery. Detection algorithms are quite complex Take time and resources. Typically too expensive to do at each allocation Run periodically or when CPU utilization goes down (which could be an indication of a deadlock). How often? Depends on how often deadlocks appear: often means we should check frequently, otherwise the set of waiting process will grow and the cost of recovery will be larger. 46 OSKomp 08 Deadlocks

46 Deadlock Detection P 5 R 1 R 3 R 4 P 5 P 1 P 2 P 3 P 1 P 2 P 3 R 2 P 4 R 5 P 4 One instance of each resource We can use resource allocation graphs (or wait-for graphs constructed from these) and check for cycles. Need to maintain the RAG/WFG, and periodically invoke an algorithm: Overhead. 47 OSKomp 08 Deadlocks

47 Deadlock Detection More instances Use variant of Banker s algorithm (sec 7.6.2). 48 OSKomp 08 Deadlocks

48 Deadlock Recovery In the detection phase, we found which processes were involved in the circular wait. Idea By terminating processes, their resources are reclaimed by the system the deadlock disappears Abort all deadlocked processes Very expensive, since many processes will have to recompute what they had done. Abort one process at a time until deadlock is broken Overhead: after each termination, re-run detection algorithm. 49 OSKomp 08 Deadlocks

49 Deadlock Recovery Process Termination Both methods may result in e.g. inconsistent data in files. If we abort one at a time, we must also consider which process to terminate (and at each stage) depending on the cost. Example considerations: Process priority - especially if users pay to get priority Accumulated runtime - shorter runtime means less recomputations Current resource allocation - number (many means more resources will be returned to the system) and type (e.g. preemtable?) Future resource requirements 50 OSKomp 08 Deadlocks

50 Deadlock Recovery Resource preemption Idea Instead of terminating process, Try preemting resources (by force releasing) until deadlock is broken. 1 Selecting a victim: Which resources? Which processes? minimize costs. 2 Rollback: The process must be able to continue running normally May require backing the process to a safe state safe state computation is difficult Total roll back. 3 Starvation: Avoid preempting/rolling back the same process again and again - cf priority scheduling and cost considerations. 51 OSKomp 08 Deadlocks