Chapter 7 – Deadlock (Pgs 283 – 306)

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

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

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

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

Deadlock (Fig 7.3)

NO Deadlock (Fig 7.4)

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

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)

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

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

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...)

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 if really desired

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)

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

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

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