SEE THE WEB EXAM NEXT WEEK HOMEWORK ASSIGNED TODAY DUE IN TWO WEEKS ---------------- Chapter 7 Deadlocks ---------------- Already defined. Permanant waiting of subset of processes. A set of processes each waiting for an event that only another process in the set can cause. Simple example with two binary semaphores S and T. Correct loop loop wait S wait S wait T wait T CS CS signal T signal T signal S signal S NCS NCS Simple example with two binary semaphores S and T. Incorrect loop loop wait S wait T wait T wait S CS CS signal T signal T signal S signal S NCS NCS HOMEWORK 7.1 7.2 View the semaphore as a resourse. A REUSUABLE resourse. Other examples are memory (allocate, free) and files (open, close). Pattern of interaction with resourse is Request Use Release This is the user view The resourse manager sees requests and releases. It issues assign/allocate and deassign/deallocate. Since all the res managers we study always respond to a release by doing the deassign/deallocate, we don't mention the deassign again I will use term allocate instead of assign. It is standard. Do NOT assume it means we are dealing with memory. From the resourse point of view it sees Request Allocate Use Release (followed by deallocate, but we won't mention it) HOMEWORK 7.9 have me do this in two weeks Picture. Resource allocation graph. Fairly std terminology. Circles for processes Rectangles for resources Arrow from process to resource for (pending) request Arrow from resourse to process for allocated resourses What can the user do? Add arrow from process to resourse Erase arrow (release) In some sense the manager is doing these What can the manager do? Reverse an arrow so it points towards the process Draw the pictures for the simple example (correct and incorrect) Can have multiple units of a resourse Draw as dots inside the box Allocation edges emanate from a dot Request edges go to the box (any dot will do) Necessary but NOT (repeat NOT!!) sufficient conditions for deadlock Due to Coffman and Havender 1. Mutual Exclusion 2. Hold and Wait 3. No preemption 4. Circular wait HOMEWORK 7.4 Strategies for dealing with deadlocks Ignore Prevent Avoid Detect (and recover) Ignoring the problem Ostrich algorithm Quite common Reasonable if deadlocks are so rare that not worth the extra coding and performance loss. Prevent Prevent one of the necessary conditions Conservative since conditions are NOT sufficient 1. Mutual Exclusion This is sharable resourses. Not applicable in general. 2. Hold and Wait Can't request if already hold E.g. All requests at beginning Can permit "phases": Release ALL at end of phase Not wonderful Low utilization Possible starvation for requester of popular resourse Can prevent starvation by stopping alloc of resourses requested by starver. But this lowers utilization more. 3. No Premption When make a request that can't be satisfied, lose all the resourses you already have Useful for resourses that can be taken and easily restored. Memory is possible Printer is not 4. Circular Wait Order the resourses and require allocations in order Variant: before request release any with bigger number Avoid Permit the necessary but NOT sufficient conditions. Tiptoe carefully through the state space to avoid deadlock states Typically need each process to predeclare the MAX number of each type of resourse it will need. Key concept is SAFE STATE A state is safe if the manager can guarantee that it can complete all the current processes (without deadlock) Does NOT mean deadlock can not be made to happen. From the initial state, a stupid manager can permit deadlock to occur. Safe means that the manager, BY CHOOSING WHAT REQUESTS TO GRANT WHEN, can keep deadlock from occuring. Unsafe state is one that is not safe. Does NOT mean deadlock will happen. Each process might be planning to release all its resources and then terminate. Unsafe means that no matter what the manager does there is a sequence of possible future actions that does lead to deadlock. Not strictly true the manager can prevent deadlock by simply not ever granting any future requests. Technically this isn't deadlock, but it is just as bad. Draw Venn dia for safe, unsafe, deadlocked states Take the simple example at beginning of lecture (2 semas) For good code all possible states are safe. For bad code get to point where manager can make a bad decision and get into unsafe state and from there cannot avoid deadlock. Example from book A good example 12 units of resource 3 processes proc claim holding 0 10 5 1 4 2 2 9 2 This is a safe state 3 free resourses Can arrange for P1 to finish Can THEN arrange for P0 to finish Can THEN arrange for P2 to finish You might think that with 3 free resources and P1 only needing 2, we have some slop (i.e. far from unsafe state). FALSE!! We are right on the edge. Let P2 request one unit and grant it. Now have proc claim allocated 0 10 5 1 4 2 2 9 3 This is UNSAFE. Assume now each processes requests the rest of its claim. P0 requests 10-5=5 P1 requests 4-2=2 P2 requests 9-3=6 You have 12 - (5+2+3) = 2 units avail You can give to P1 and wait for it to finish. Then you have 4 free, which is NOT enough for either P0 or P2. Resource-allocation graph algorithm Put in dased lines for claim edge pointing like request When make a request turn line solid When make a release put back claim Manager does not grant request if get a cycle (dashed lines count) Show for simple example (2 semas) bad code Works only for SINGLE UNIT resources since only one claim Banker's algorithm Dijkstra Works for general case Like a banker with money (kinda sorta) Available[j] is the number of units of j currently avail Claim[i,j] is the claim of process i for resource j Allocated[i,j] is the number of units of j that i has now MightStillNeed = Claim - Allocated X <= Y means X[i] <= Y[i] all i X < Y means X <= Y and X != Y Does NOT mean X[i] < Y[i] all i Algorithm for safety 1. (Initialize) CanAssign = Available; Finished[i] = false all i 2. (Find a process we can guarantee will finish) Find an i such that Finished[i] = false MightStillNeed[i] <= Available If no such i, goto 4 3. (Update state assuming i finished) Finished[i] = true Available += Allocated[i] 4. (Could everyone finish) If Finished[i] = true all i, safe; otherwise unsafe Manager's algorithm when receives a Request from i 1. (Check for legality) If NOT Request <= MightStillNeed[i], error 2. (Check if currently possible) IF NOT Request <= Available, must wait (exit algorithm) 3. Try the allocation Available -= Request Allocated[i] += Request MightStillNeed[i] -= Request If new state is safe grant, else make wait and undo Managers algorithm when receive a Release from i Book "forgot it" so HOMEWORK Give manager's alg for release HOMEWORK 7.6, 7.11 Do the good example (P0, P1, P2) Detect (and prevent) When single unit resources just need the WAIT-FOR graph Take resource-alloc graph and remove the resource nodes When have edge going in and out of resource node draw edge from source process to sink. This is just right! Get edge iff Pi currently "waits for" Pj Deadlock iff (if and only if) have cycle For multiple-unit resources need an alg like bankers. We skip it How often should we look for deadlock Not clear. Look more often if deadlock more likely What to do if find a deadlock Shoot 'em all Shoot 'em one by one until deadlock gone Preempt a resource if possible Mixed solutions Idea is different resources are handled differently Example Internal to OS resources (e.g PCB, open file table, etc) Prevent deadlocks by ordering requests. Feasible since have total control Central memory Prevent via preemption Feasible since memory state can be restored Job resources Avoidance if jobs pre-declare max Detection and recovery (probably shooting) if not Swap space Same as above job resources If know exact need (not just max), preallocate