1. Chapter 5 Process Management 2015 - Semester 2

2. Objectives  What is a deadlock?  Seven cases of deadlocks  Conditions of deadlocks –Mutual exclusion –Recourse holding –No preemption –Circular wait  Modelling deadlocks Resource allocation graphs  Strategies for handling deadlocks Prevention Avoidance Detection Recovery  Banker’s algorithm  Safe and unsafe states  Starvation

3. Deadlocks  Resource sharing –Memory management and processor sharing  Many programs competing for limited resources  Lack of process synchronization consequences –Deadlock: A problem occurring when the resources needed by some jobs to finish execution are held by other jobs, which, in turn, are waiting for other resources to become available. Two or more jobs placed in HOLD state Jobs waiting for unavailable vital resource System comes to standstill Resolved via external intervention –Starvation Infinite postponement of job

4. Deadlocks (cont.)  Affects entire system –Affects more than one job Not just a few programs –All system resources become unavailable  More common in interactive systems  Real-time systems –Deadlocks quickly become critical situations  No simple and immediate solution

5. Deadlocks (cont.) EXAMPLES: "It takes money to make money". “You can't get a job without experience; you can't get experience without a job”. BACKGROUND: The cause of deadlocks: Each process needing what another process has. This results from sharing resources such as memory, devices, links. Under normal operation, a resource allocations proceed like this: 1.Request a resource. 2.Use the resource. 3.Release the resource.

6. Deadlocks (cont.)

7. Seven Cases of Deadlocks  Non-sharable /non-preemptable resources –Allocated to jobs requiring same type of resources  Resource types locked by competing jobs –File requests –Databases –Dedicated device allocation –Multiple device allocation –Spooling –Disk sharing –Network Homework: Read about these cases in the textbook.

8. Conditions for Deadlocks  Four conditions simultaneously occurring prior to deadlock: –Mutual exclusion –Resource holding –No preemption –Circular wait  All needed by operating system –Must recognize simultaneous occurrence of four conditions  Resolving deadlock –Removal of one condition

9. Conditions for Deadlocks (cont.) Mutual Exclusion  Allowing only one process access to dedicated resource.  If another process requests that resource, the requesting process must be delayed until the resource has been released. Resource holding  a process that holding at least one resource (and not releasing it) and is waiting to acquire additional resources held by other processes.

10. Conditions for Deadlocks (cont.) No preemption  Lack of temporary reallocation of resources  A resource can be released only voluntarily by the process holding it, after that process has completed its task. Circular wait  Must be in a circular chain of 2 or more processes.  Each process is waiting for a resource held by the next member in the chain or circle Waiting voluntarily resource release by another so at least one can continue 4 All four required for deadlock occurrence 4 Deadlock remains until one condition is removed

11. Modeling Deadlocks  Directed Graphs Process Resource Request a Resource Hold a Resource Deadlock –When there is a circle R A A B A R R RS A

12. Modeling Deadlocks (cont.) Basic facts: No circles => no deadlocks If graph contains a circle: If only one instance per type, then deadlock. If several instances per resource type, then possibility of deadlock. (figure 5.7) In (a), Resource 1 is being held by Process 1 and Resource 2 is held by Process 2 in a system that is not deadlocked. In (b), Process 1 requests Resource 2 but doesn’t release Resource 1, and Process 2 does the same— creating a deadlock. (If one process released its resource, the deadlock would be resolved.) © Cengage Learning 2014

13. Modeling Deadlocks (cont.)

14. Deadlocks Resource allocation graph Resource allocation graph with a deadlock Resource allocation graph with a cycle but no deadlock

15. Modelling Deadlocks  Three graph scenarios to help detect deadlocks –System has three processes (P1, P2, P3) –System has three resources (R1, R2, R3)  No deadlock –Resources released before next process request (table 5.1) Scenario 1. These events are shown in the directed graph in Figure 5.8. © Cengage Learning 2014 (figure 5.8) First scenario. The system will stay free of deadlocks if each resource is released before it is requested by the next process. © Cengage Learning 2014

16. Modelling Deadlocks  Three graph scenarios to help detect deadlocks –System has three processes (P1, P2, P3) –System has three resources (R1, R2, R3)  Deadlock –Processes waiting for resource held by another (table 5.2) Scenario 2. This sequence of events is shown in the two directed graphs shown in Figure 5.9. © Cengage Learning 2014 (figure 5.9) Second scenario. The system (a) becomes deadlocked (b) when P3 requests R1. Notice the circular wait. © Cengage Learning 2014

17. Modelling Deadlocks  Three graph scenarios to help detect deadlocks –System has three processes (P1, P2, P3) –System has three resources (R1, R2, R3) No deadlock –Resources released before deadlock (table 5.3) Scenario 3. This sequence of events is shown in the directed graph in Figure 5.10. © Cengage Learning 2014 (figure 5.10) The third scenario. After event 4, the directed graph looks like (a) and P2 is blocked because P1 is holding on to R1. However, event 5 breaks the deadlock and the graph soon looks like (b). Again there is a blocked process, P3, which must wait for the release of R2 in event 7 when the graph looks like (c). © Cengage Learning 2014

18. Strategies for Handling Deadlocks Ignore Deadlocks Ensure deadlock never occurs using either: Prevention Prevent any one of the 4 conditions (mutual exclusion, resource holding, no preemption or circular wait) from happening. Avoidance Allow all deadlock conditions, but calculate cycles about to happen and stop dangerous operations.. Allow deadlock to happen. This requires using both: Detection Know a deadlock has occurred. Recovery Resume system normalcy quickly and gracefully and regain the resources

19. Strategies for Handling Deadlocks (cont.)  Prevention eliminates one of four conditions –Complication: same condition cannot be eliminated from every resource. –Mutual exclusion Some resources must allocate exclusively Bypassed if I/O device uses spooling Shared entities (read only files) don't need mutual exclusion (and aren’t susceptible to deadlock). Prevention not always possible since some devices are intrinsically non-sharable –Resource holding One approach requires that each process be allocated all of its resources before it begins executing Alternatively, only allow a process to request resources when it currently has none Bypassed if all jobs request every necessary resource are known at creation time A particular resource can only be requested when no others are being held. A sequence of resources is always collected beginning with the same one. Multiprogramming degree significantly decreased Idle peripheral devices Utilization is low, starvation possible.

20. Strategies for Handling Deadlocks (cont.)  Prevention (cont.) –No preemption Release any resource already being held if the process can't get an additional resource Bypassed if operating system allowed to deallocate resources from jobs Okay if job state easily saved and restored Not accepted to preempt dedicated I/O device or files during modification Allow preemption - if a needed resource is held by another process, which is also waiting on some resource, steal it. Otherwise wait. –Circular wait Bypassed if operating system prevents circle formation Use hierarchical ordering scheme Requires jobs to anticipate resource request order Difficult to satisfy all users EACH of these prevention techniques may cause a decrease in utilization and/or resources. For this reason, prevention isn't necessarily the best technique. Prevention is generally the easiest to implement.

21. Strategies for Handling Deadlocks (cont.) Avoidance If we have prior knowledge of how resources will be requested, it's possible to determine if we are entering an "unsafe" state. Possible states are: Deadlock No forward progress can be made. Unsafe state A state that may allow deadlock. Safe state A state is safe if a sequence of processes exist such that there are enough resources for the first to finish, and as each finishes and releases its resources there are enough for the next to finish. The rule is simple: If a request allocation would cause an unsafe state, do not honor that request.

22. Strategies for Handling Deadlocks (cont.)  Avoidance: If the OS cannot remove one of the deadlock condition, it can avoid one if: –System knows ahead of time the sequence of requests associated with each active process.  Dijkstra’s Bankers Algorithm –Regulates resources allocation to avoid deadlock No customer granted loan exceeding bank’s total capital All customers given maximum credit limit No customer allowed to borrow over limit Sum of all loans will not exceed bank’s total capital

23. Handling Deadlocks (cont.) Banker’s algorithm

24. Handling Deadlocks (cont.) Banker’s algorithm

25. Safe state 1 resource with 12 units of that resource available. Current State: Free = (12 – (5 + 2 + 2)) = 3

26. Unsafe state What if P2 requests 1 more and is allocated 1 more? New state:

27. Handling Deadlocks (cont.)  Operating systems deadlock avoidance assurances –Never satisfy request if job state moves from safe to unsafe Identify job with smallest number of remaining resources Number of available resources => number needed for selected job to complete Block request jeopardizing safe state

28. Handling Deadlocks (cont.)  Problems with the Banker’s Algorithm –Jobs must state maximum number needed resources –Requires constant number of total resources for each class –Number of jobs must remain fixed –Possible high overhead cost incurred –Resources not well utilized Algorithm assumes worst case –Scheduling suffers Result of poor utilization Jobs kept waiting for resource allocation

29. Handling Deadlocks (cont.)  Detection: build directed resource graphs –Look for cycles  Algorithm detecting circularity –Executed whenever appropriate  Detection algorithm: –Remove process using current resource and not waiting for one –Remove process waiting for one resource class Not fully allocated –Go back to step 1 Repeat steps 1 and 2 until all connecting lines removed Look for the examples in the textbook

30. Handling Deadlocks (cont.)  Recovery –Deadlock untangled once detected –System returns to normal quickly  All recovery methods have at least one victim  Recovery methods –Terminate every job active in system Restart jobs from beginning –Terminate only jobs involved in deadlock Ask users to resubmit jobs –Identify jobs involved in deadlock Terminate jobs one at a time

31. Handling Deadlocks (cont.)  Recovery methods (cont.) –Interrupt jobs with record (snapshot) of progress –Select non-deadlocked job Preempt its resources Allocate resources to deadlocked process –Stop new jobs from entering system Allow non-deadlocked jobs to complete Releases resources when complete No victim

32. Handling Deadlocks (cont.)  Factors to consider: –Select victim with least-negative effect on the system –Most common Job priority under consideration: high-priority jobs usually untouched CPU time used by job: jobs close to completion usually left alone Number of other jobs affected if job selected as victim Jobs modifying data: usually not selected for termination (a database issue)

33. Starvation  Job execution prevented –Waiting for resources that never become available –Results from conservative resource allocation  Example –“The dining philosophers” by Dijkstra  Starvation avoidance –Implement algorithm tracking how long each job waiting for resources (aging) –Block new jobs until starving jobs satisfied

34. Starvation

35. Homework Read chapter 5 in the textbook!! End