1. Understanding Operating Systems Fifth Edition Chapter 5 Process Management

2. Understanding Operating Systems, Fifth Edition2 Deadlock Resource sharing: Memory and CPU sharing Many programs competing for limited resources Lack of process synchronization consequences –Deadlock: “deadly embrace” Two or more jobs placed in HOLD state Jobs waiting for unavailable vital resource System comes to standstill OS can’t resolve the deadlock; external intervention bys users and/or sys admin needed to terminate jobs –Starvation Infinite postponement of job

3. Understanding Operating Systems, Fifth Edition3 Deadlock (continued) More serious than starvation Affects entire system –Affects more than one job Not just a few programs –All system resources become unavailable Example: traffic jam (Figure 5.1) More prevalent in interactive systems Real-time systems –Deadlocks quickly become critical situations No simple and immediate solution

4. Understanding Operating Systems, Fifth Edition4 Deadlock (continued)

5. Understanding Operating Systems, Fifth Edition5 Seven Cases of Deadlock Deadlocks usually happen when non-sharable and non- preemptable resources (such as files, printers, and scanners) are allocated to jobs that eventually require other such resources which have been locked by other jobs. Resource types locked by competing jobs –File requests –Databases –Dedicated device allocation –Multiple device allocation –Spooling –Disk sharing –Network

6. Understanding Operating Systems, Fifth Edition6 Case 1: Deadlocks on File Requests Jobs request and hold files for execution duration Example (Figure 5.2) –Two programs (P1, P2) and two files (F1, F2) –Deadlock sequence P1 has access to F2 and also requires F1 P2 has access to F1 and also requires F2 –Deadlock remains Until one program withdrawn or Until one program forcibly removed and file released –Other programs requiring F1 or F2 Put on hold for duration of situation

7. Understanding Operating Systems, Fifth Edition7 Case 1: Deadlocks on File Requests (continued)

8. Understanding Operating Systems, Fifth Edition8 Case 2: Deadlocks in Databases A deadlock can also occur if two processes access and lock records in a database. Locking: Technique to guarantee the integrity of the data through which the user locks out all other users while working with the database. –Three locking levels Entire database for duration of request Subsection of database Individual record until request completed

9. Understanding Operating Systems, Fifth Edition9 Case 2: Deadlocks in Databases (continued) Example: two processes (P1 and P2) –Each needs to update two records (R1 and R2) –Deadlock sequence P1 accesses R1 and locks it P2 accesses R2 and locks it P1 requests R2 but locked by P2 P2 requests R1 but locked by P1 Race between processes –Results when locking not used –Causes incorrect final version of data –Depends on process execution order

10. Understanding Operating Systems, Fifth Edition10 Case 2: Deadlocks in Databases (continued)

11. Understanding Operating Systems, Fifth Edition11 Case 3: Deadlocks in Dedicated Device Allocation Limited number of dedicated devices (devices that can be assigned to a single process at a time) Example –Two programs (P1, P2) Need two tape drives each Only two tape drives in system –Deadlock sequence P1 requests tape drive 1 and gets it P2 requests tape drive 2 and gets it P1 requests tape drive 2 but blocked P2 requests tape drive 1 but blocked

12. Understanding Operating Systems, Fifth Edition12 Case 4: Deadlocks in Multiple Device Allocation Several processes request and hold dedicated devices Example (Figure 5.4) –Three programs (P1, P2, P3) –Three dedicated devices (scanner, printer, plotter) –Deadlock sequence P1 requests and gets scanner P2 requests and gets printer P3 requests and gets the plotter P1 requests printer but blocked P2 requests plotter but blocked P3 requests scanner but blocked

13. Understanding Operating Systems, Fifth Edition13 Case 4: Deadlocks in Multiple Device Allocation (continued)

14. Understanding Operating Systems, Fifth Edition14 Case 5: Deadlocks in Spooling Virtual device –Dedicated device made sharable –Example: The printer has been transformed into a sharable device by installing a high-speed disk between the printer and the CPU. Spooling –Process The disk accepts output from several users Acts as temporary storage for output Output resides in disk area until printer accepts job data

15. Understanding Operating Systems, Fifth Edition15 Case 5: Deadlocks in Spooling (continued) Deadlock sequence –Printer needs all job output before printing begins Spooling system fills disk space area No one job has entire print output in spool area Results in partially completed output for all jobs Results in deadlock

16. Understanding Operating Systems, Fifth Edition16 Case 6: Deadlocks in a Network A network that’s congested or has filled a large percentage of its I/O queues can become deadlocked if it doesn’t have protocols controlling the network message flow. Example (Figure 5.5) –Seven computers on network Each on different nodes –Direction of arrows Indicates message flow –Deadlock sequence All available buffer space fills

17. Understanding Operating Systems, Fifth Edition17 Case 6: Deadlocks in a Network (continued)

18. Understanding Operating Systems, Fifth Edition18 Case 7: Deadlocks in Disk Sharing Competing processes send conflicting commands –Scenario: disk access Example (Figure 5.6) –Two processes –Each process waiting for I/O request One at cylinder 20 and one at cylinder 310 –Deadlock sequence Neither I/O request satisfied Device puts request on hold while attempting to fulfill other request for each request –Livelock results

19. Understanding Operating Systems, Fifth Edition19 Case 7: Deadlocks in Disk Sharing (continued)

20. Understanding Operating Systems, Fifth Edition20 Conditions for Deadlock Four conditions simultaneously occurring prior to deadlock or livelock –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 resolves the deadlock. Although this concept is obvious, it isn’t easy to implement.

21. Understanding Operating Systems, Fifth Edition21 Conditions for Deadlock (continued) Mutual exclusion –Allowing only one process access to dedicated resource Resource holding –A process holds on to a resource, does not release it and waits for the other job to retreat No preemption –A resource is allocated to a process for as long as needed. Lack of temporary reallocation of resources.

22. Understanding Operating Systems, Fifth Edition22 Conditions for Deadlock (continued) Circular wait –Each process involved in the impasse is waiting for another process to voluntarily release a resource so at least one process can continue All four conditions are required for deadlock occurrence but if one condition is removed then the deadlock is broken.

23. Understanding Operating Systems, Fifth Edition23 Modeling Deadlocks Directed graphs –Used to model deadlocks –Circles represent processes –Squares represent resources –Solid arrow from a resource to a process Process is holding the resource –Solid arrow from a process to a resource Process is waiting for the resource –Arrow direction indicates flow –If there’s a cycle in the graph then there’s a deadlock involving the processes and the resources in the cycle

24. Understanding Operating Systems, Fifth Edition24 Modeling Deadlocks (continued)

25. Understanding Operating Systems, Fifth Edition25 Modeling Deadlocks (continued) Three graph scenarios to help detect deadlocks –System has three processes (P1, P2, P3) –System has three resources (R1, R2, R3) Scenario one: no deadlock –Resources released before next process request Scenario two: deadlock –Processes waiting for resource held by another Scenario three: no deadlock –Resources released before deadlock

26. Understanding Operating Systems, Fifth Edition26 Modeling Deadlocks (continued) No deadlock –Resources released before next process request

27. Understanding Operating Systems, Fifth Edition27 Modeling Deadlocks (continued)

28. Understanding Operating Systems, Fifth Edition28 Modeling Deadlocks (continued) Deadlock –Processes waiting for resource held by another

29. Understanding Operating Systems, Fifth Edition29 Modeling Deadlocks (continued)

30. Understanding Operating Systems, Fifth Edition30 Modeling Deadlocks (continued) No deadlock –Resources released before deadlock

31. Understanding Operating Systems, Fifth Edition31 Modeling Deadlocks (continued)

32. Understanding Operating Systems, Fifth Edition32 Modeling Deadlocks (continued) Examples studied so far involved the allocation of one or more resources of different types (e.g. a printers and a disk drive) to a process. The directed graphs can be expanded to include several resources of the same type (e.g. a tape drive) that can be allocated individually or in groups to the same process. These graph clusters devices of the same type into one entity (shown in Fig. 5.11 as a rectangle).

33. Understanding Operating Systems, Fifth Edition33 Modeling Deadlocks (continued)

34. Understanding Operating Systems, Fifth Edition34 Strategies for Handling Deadlocks The requests and releases of resources are received in an unpredictable order making it very difficult to design a foolproof preventive policy. Operating systems use one of these strategies to deal with deadlocks: Prevention –Prevent occurrence of one condition Mutual exclusion, resource holding, no preemption, circular wait Avoidance –Avoid deadlock if it becomes probable Detection and Recovery –Detect deadlock when it occurs –Recover gracefully

35. Understanding Operating Systems, Fifth Edition35 Strategies for Handling Deadlocks (continued) Prevention eliminates one of four conditions –Complication: same condition can’t be eliminated from every resource –Mutual exclusion Some resources must allocated exclusively to one user (e.g. memory, CPU) Bypassed if I/O device uses spooling (e.g. using a print spooler on a printer). However, we may be trading one type of deadlock for another (Case 3: Deadlocks in Dedicated Device Allocation for Case 5: Deadlocks in Spooling) –Resource holding Job holds on to one resource while waiting for another that’s not yet available. Sidestepped if jobs request every necessary resource at creation time Multiprogramming degree significantly decreased Idle peripheral devices Can be successfully used in batch systems but doesn’t work well in interactive systems

36. Understanding Operating Systems, Fifth Edition36 Strategies for Handling Deadlocks (continued) Prevention (continued) –No preemption 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 devices or files during the modification process –Circular wait Bypassed if operating system prevents circle formation Requires jobs to anticipate resource request order Difficult to satisfy all users

37. Understanding Operating Systems, Fifth Edition37 Strategies for Handling Deadlocks (continued) Avoidance: even if one of the 4 conditions to prevent deadlock cannot be removed, the OS can avoid deadlock if the OS knows ahead of time the sequence of requests associated with each active process. Dijkstra’s Bankers Algorithm –Algorithm to regulate resource allocation to avoid deadlock. It is based on a bank with a fixed amount of capital that operates on the following principles: 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

38. Understanding Operating Systems, Fifth Edition38 Strategies for Handling Deadlocks (continued)

39. Understanding Operating Systems, Fifth Edition39 Strategies for Handling Deadlocks (continued)

40. Understanding Operating Systems, Fifth Edition40 Strategies for Handling Deadlocks (continued)

41. Understanding Operating Systems, Fifth Edition41 Strategies for Handling Deadlocks (continued)

42. Understanding Operating Systems, Fifth Edition42 Strategies for Handling Deadlocks (continued) 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

43. Understanding Operating Systems, Fifth Edition43 Strategies for Handling Deadlocks (continued) Problems with the Banker’s Algorithm –Jobs must predict maximum number needed resources. This is impractical for interactive systems. –Requires constant number of total resources for each class. –Number of jobs must remain fixed. This is not possible in an interactive system. –Possible high overhead cost incurred by running the avoidance algorithm because it must be invoked for every request. –Resources not well utilized Algorithm assumes worst case –Scheduling suffers Result of poor resource utilization Jobs kept waiting for resource allocation

44. Understanding Operating Systems, Fifth Edition44 Strategies for Handling Deadlocks (continued) Detection: build directed resource graphs –Look for cycles Algorithm detecting circularity –Executed whenever appropriate Detection algorithm used to reduce directed graphs. –Remove process using current resource and not waiting for one –Repeat step until all connecting lines removed

45. Understanding Operating Systems, Fifth Edition45 Strategies for Handling Deadlocks (continued)

46. Understanding Operating Systems, Fifth Edition46 Strategies for Handling Deadlocks (continued)

47. Understanding Operating Systems, Fifth Edition47 Strategies for Handling Deadlocks (continued) Recovery –Deadlock untangled once detected –System returns to normal quickly All recovery algorithms require at least one victim (an expendable job) Recovery methods –Terminate every job active in system Restart all 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, checking to see if the deadlock is broken after each removal, until the deadlock is resolved.

48. Understanding Operating Systems, Fifth Edition48 Strategies for Handling Deadlocks (continued) Recovery methods (continued) –Select a non-deadlocked job Preempt its resources Allocate resources to a deadlocked process –Stop new jobs from entering system Allow non-deadlocked jobs to complete Releases resources when complete No victim Will work only if the number of available resources exceeds that needed by at least one of the deadlocked jobs to run.

49. Understanding Operating Systems, Fifth Edition49 Strategies for Handling Deadlocks (continued) 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) because a database that is only partially updated is only partially correct (consistency and validity of the database must not be compromised).

50. Understanding Operating Systems, Fifth Edition50 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

51. Understanding Operating Systems, Fifth Edition51 Starvation (continued)

52. Understanding Operating Systems, Fifth Edition52 Starvation (continued)