Deadlock Questions? ! What is a deadlock? CSCI [4|6]730 ! What - PDF document

Deadlock Questions? ! What is a deadlock? CSCI [4|6]730 ! What causes a deadlock? Operating Systems ! How do you deal with (potential) deadlocks? Deadlock Maria Hybinette, UGA Maria Hybinette, UGA Deadlock: What is a deadlock? Example (Review): Two Threads? No problem -- ! I don ’ t back ! I do! ! up for idiots ! ! Two threads access two shared variables, A and B » Variable A is protected by lock a » Variable B by lock b ! How to add lock and unlock statements? Thread Maria Thread Tucker Deitel & Deitel anecdote lock(a); lock(b) ! All are waiting for a resource that is held by another A += 10; B += 10; waiting entity. Since all are waiting, none can provide lock(b); lock(a); Does this B += 20; A += 20; any of the things being waited for (they are blocked). work? ! Example: narrow bridge (resource) -- A += B; A += B; unlock(b) unlock(a); » if a deadlock occurs, resolved if one car back up A += 30 B += 30 (preempts resource and rollback). unlock(a) unlock(b); Maria Hybinette, UGA Maria Hybinette, UGA Example: Maria & Tucker Representing Deadlock ! Two common ways of representing deadlock: » Vertices (circles or rectangles) Maria gets lock a Maria waits for lock b – threads (or processes) in system Thread Maria – resources [types] (e.g., locks, semaphores, printers) Tucker gets lock b Tucker waits lock b » Edges : indicates either (determined by direction): Thread Tucker – `waiting for ’ or `wants ’ (head of arrow on resource) OR – `held by ’ (head of arrow on thread) Wait-For Graph ! Resource Allocation Graph ! Time Thread Maria Thread Tucker lock(a); lock(b) waits wants ! held by ! A += 10; B += 10; “ waiting for ” ! R 1 ! lock(b); lock(a); B += 20; A += 20; T 1 ! T 2 ! T 1 ! T 2 ! A += B; A += B; unlock(b) unlock(a); R 2 ! A += 30 B += 30 unlock(a) unlock(b); held by ! wants ! Maria Hybinette, UGA Maria Hybinette, UGA

Conditions for Deadlock What to do: Handling Deadlock All for conditions must hold simultaneously ! Ignore 1. » Easiest and most common approach (e.g., UNIX). ! Mutual exclusion: Deadlock prevention 2. » Resource cannot be shared Ostrich algorithm » Ensure deadlock does not happen » Requests are delayed until resource is released » Ensure at least one of 4 conditions does not occur ! Hold and wait: 1. Hold&Wait, No Preemption, Circularity, Mutual Exclusion » Thread holds one resource while it waits for another 2. System build so deadlock cannot happen ! No preemption: Deadlock detection and recovery 3. » previously granted resources cannot forcibly be taken away » Allow deadlocks, but detect when occur ! Circular wait: » Recover and continue » Circular dependencies exist in “ waits-for ” or “ resource- Deadlock avoidance 4. allocation ” graphs » Ensure deadlock does not happen » Each is waiting for a resource held by next member of the » Use information about resource requests to dynamically chain. avoid unsafe situations (Thursday) All for conditions must hold simultaneously ! Maria Hybinette, UGA Maria Hybinette, UGA Deadlock Prevention: Deadlock Prevention Mutual Exclusion Mutual exclusion Mutual exclusion Hold and wait Hold and wait ! Approach ! No mutual exclusion --> Make No preemption No preemption resource sharable ; examples: » Ensure 1 of 4 conditions cannot occur Circular wait Circular wait » Negate each of the 4 conditions » Read-only files ! No single approach is appropriate (or » Printer daemon needs exclusive access to the printer, there is only one possible) for all circumstances printer daemon -- uses spooling. 10 Maria Hybinette, UGA Maria Hybinette, UGA Deadlock Prevention Deadlock Prevention Hold and Wait Hold and Wait Mutual exclusion Mutual exclusion Hold and wait Hold and wait Two General Approaches: Two Approaches: ! No preemption ! No preemption Circular wait Circular wait 1. Only request resources when it does 2. Atomically acquire all resources at not hold other resources once (all or none) – release resources before requesting » Example: Single lock to protect all new ones (other variations - e.g., release access Thread Maria Thread Tucker to one variable earlier) lock(a); lock(b) B += 10; A += 10; Thread Maria Thread Tucker unlock(a) Unlock(b); lock(a); lock(b); lock(AB) A += 20; lock(AB); B += 20; B += 10; A += 10; unlock(b) unlock(a); A += 20; lock(b) B += 20; lock(a) A += 30 B += 30 B += 30 A += 30 unlock(AB); unlock(b); unlock(AB) unlock(a) 11 12 Maria Hybinette, UGA Maria Hybinette, UGA

Deadlock Prevention Deadlock Prevention Hold and Wait No Preemption Mutual exclusion Mutual exclusion Two Approaches: ! Hold and wait Hold and wait 1. Preempt requestors resource No preemption No preemption Summary the Two Approaches: ! – Example: B is holding some resources and Circular wait Circular wait then requests additional resources that are 1. Only request resources when it does not hold other held by other threads, then B releases all its resources resources (and start over) 2. Atomically acquire all resources at once 2. Preempt holders resource Problems: ! – Example: A waiting for something held by B, then take resource away from B and give them to A (B » Low resource utilization: ties up resources other starts over). processes could be using Not possible if resource cannot be saved ! » May not know required resources before execution and restored » Starvation: A thread that need popular resources » Can ’ t take away a lock without causing may wait forever problems Only works for some resources (e.g., CPU ! and memory) » May cause thrashing. 13 14 Maria Hybinette, UGA Maria Hybinette, UGA Deadlock Prevention Circular Wait Condition Deadlock Detection & Recovery Mutual exclusion Hold and wait ! Impose ordering on resources 1. Allow system to enter deadlock state No preemption Circular wait » Give all resources a ranking or priority; 2. Detection algorithm must acquire highest ranked resource 3. Recovery scheme first. – Dijskstra: Establishing the convention that all resources will be requested in order, and released in reverse order, 15 16 Maria Hybinette, UGA Maria Hybinette, UGA Deadlock Detection Side Node Single Instance of Each Resource Type ! Maintain a wait-for graph (it works on RAGS as well) ! Discovering a deadlock after it occurs, is » Nodes are processes. decidable » Simplify: removes resource nodes and collapse edges » P i ! P j if P i is waiting for P j . ! Discovering it ‘before’ it occurs, is in general ! Periodically invoke an algorithm that searches for a un-decidable: same as the halting problem. cycle in the graph. Resource Allocation Graphs (RAGs) 17 18 Maria Hybinette, UGA Maria Hybinette, UGA

Example Code : A depth first search to find circles Deadlock detection For each node in the graph: ! Do a depth-first-search on the resource L = {empty list} and Nodes = {list of all unvisited nodes}; allocation graph (RAG) current node = initial node // pick one randomly D, E, G ? while( current node is not the initial node twice ) then done L.enqueue(current node); // add to node to end of L are deadlocked if( current node is in L twice ) A, C, F ? there is a cycle " cycle and return are not deadlocked because S can if( there is an unmarked arc explore that one ) be allocated to either and then the mark the arc as visited and use destination as new others can take turn to complete current node else // backtrack go back to previous node Back to initial node there is no cycle 19 20 Maria Hybinette, UGA Maria Hybinette, UGA Example: Deadlock Detection Example: Deadlock Detection ! Do a depth-first-search on the resource ! Do a depth-first-search on the resource allocation graph allocation graph Initialize a list to the empty list, designate arcs as ‘ unvisited ’ T T 21 22 Maria Hybinette, UGA Maria Hybinette, UGA Example: Deadlock Detection Example: Deadlock Detection ! Do a depth-first-search on the resource ! Do a depth-first-search on the resource allocation graph allocation graph T T 23 24 Maria Hybinette, UGA Maria Hybinette, UGA

Deadlock Detection with Deadlock Detection Algorithm: Multiple Resources Multiple Resource Instances Doesn ’ t Change ! Theorem: If a graph does not contain a cycle then no processes are deadlocked » A cycle in a RAG is a necessary condition for deadlock » Is it a sufficient condition? Printers P2 waiting holding What I have (now!) What I am requesting now P1 P3 ! Available: Indicates the number of available resources of each type (m) CD-WR holding waiting ! Allocation: Number of resources of each type currently allocated (nxm) ! Request: current requests of each thread (nxm) P4 25 26 holding » If Request [ i j ] = k , then process P i is requesting k more instances of type. R j . Maria Hybinette, UGA Maria Hybinette, UGA Example Detection algorithm A marked process means it can run to completion ! Is there a possible allocation sequence of resources so that each process can complete? Initially all processes are unmarked. 1. Look for an unmarked process Pi, whose needs can be satisfied (all): » the i th whole row of R (need) is less than or equal to A (i.e, all the resource(s) is/are available) 2. If such a process is found, add the i-th row of C to A, mark the process and go back to step 1 (it is done processing and can release its resource) 3. If no such process exists the algorithm terminates If all marked, no deadlock, 27 28 o/w deadlocked Maria Hybinette, UGA Maria Hybinette, UGA Detection algorithm Detection algorithm Can we satisfy a ROW in the Request Matrix? 29 30 Maria Hybinette, UGA Maria Hybinette, UGA