1. Chapter 7 – Deadlock (Pgs 283 – 306)

2. Overview  When a set of processes is prevented from completing because each is preventing the other from accessing resources that the other needs, we say that deadlock occurs  Deadlock is a cause of process starvation, but is not the only cause  Deadlock is not monitored, identified, or handled by the O/S, it is a programmer responsibility to prevent

3. Resources  Memory, CPU cycles, files, I/O devices (network, printer, keyboard, mouse) can be partitioned into sets  All the members of a set are equivalent such that a process can use any member, e.g., two identical printers  A resource must be (in this order): 1. Requested (and waited for until available) 2. Used 3. Released  Generally, when one process has a resource, another process cannot use it

4. Necessary Conditions 1. Mutual Exclusion: At least one resource must be held in a non-sharable mode 2. Hold and Wait: A process must be holding at least one resource and waiting to acquire some other resource 3. No Pre-emption: A resource cannot be involuntarily taken away from a process that is using it 4. Circular Wait: It must be possible to structure the waits such that, P1 w. P2, P2 w. P3,..., Pn w. P1

5. Resource Allocation Graphs  Two types of nodes: 1. Processes 2. Resources  Directed edges go 1. from a Process to a Resource (request) 2. from a Resource to a Project (assignment)  A cycle in the graph indicates deadlock

6. Deadlock (Fig 7.3)

7. NO Deadlock (Fig 7.4)

8. Three Solutions 1. Prevent/Avoid Deadlock  Prevention: When deadlock is going to occur, stop it  Avoidance: Reschedule processes so that deadlock does not have to be prevented 2. Detect and Recover 3. Ignore the Issue  Generally, most O/S use solution 3 and expect programmers to deal with the issue

9. Prevention (via 4 conditions)  Disallow anything that requires mutual exclusion (unreasonable)  Do not allow a process to request a resource while it is holding one (or) only let a process run if all resources are available (inefficient)  Pre-empt a process to break a cycle (only effective if preemption can later be effectively reversed, e.g., not printing)  Order resources and allow them only to be acquired and held in order (complex, but effective)

10. Avoidance  Requires knowledge of which resources a process will use (process can declare this)  Goal is to always maintain a "safe state" for which some sequence of (deadlock free) resource allocations is possible  Two common algorithms: 1. Resource allocation graph algorithm 2. Bankers algorithm

11. Resource Graph Prevention  Put in temporary edges that represent what a process could use (claim edges)  If these edges cause a cycle, then there is an unsafe state  Prevent unsafe states by not allowing a process to use any resources until it can do so without putting the system in an unsafe state  Not effective for multiple instances of each resource

12. Banker's Algorithm  Less efficient than resource allocation graph algorithm  Again requires a process to know all the resources it is going to need  Safety (sub) Algorithm: Checks if a system is in a safe state  Request (sub) Algorithm: Determines if a request is possible  I am unaware of any O/S that actually uses the Banker's Algorithm (or ever will...)

13. Deadlock Detection  Too inefficient to actually do this for every resource request  Could just do it at regular intervals (but nobody does)  Does not fix the problem  A lot of effort for a generally rare problem (programmers like to avoid deadlock anyways)  Use algorithm 7.6.2 if really desired

14. Recovery  Process Termination (2 approaches) 1. Abort all known deadlocked processes 2. Abort one at a time until deadlock eliminated  Termination can leave a resource (e.g., file) in an invalid state  Consider: 1. Process priority (importance of job) 2. How long it ran and how long it will take to complete (preserve computation) 3. Which resources it uses (1 vs many)

15. Resource Pre-Emption  Alternative to Process Termination  Similar factors to consider  Effective for some resources for which invalid state is not likely or hard to handle  Maybe be repairable using rollback  May cause starvation if performed multiple times

16. Ignoring the Problem  More likely due to increasing concurrency  Less likely as many resources now designed for concurrency  Programmers more able to deal with the issue than in the past  More of interest to researchers than to practictioners  More effort to avoid/detect than is probably worth making

17. To Do:  Begin Assignment 2 in Lab  Read Chapter 7 (pgs 283-306; this lecture)  Start reading Chapter 8 (next lecture)