6 Deadlocks 6 1 Deadlocks with Reusable and

6. Deadlocks 6. 1 Deadlocks with Reusable and Consumable Resources 6. 2 Approaches to the Deadlock Problem 6. 3 A System Model – Resource Graphs – State Transitions – Deadlock States and Safe States 6. 4 Deadlock Detection – Reduction of Resource Graphs – Special Cases of Deadlock Detection 6. 5 Recovery from Deadlock 6. 6 Dynamic Deadlock Avoidance – Claim Graphs – The Banker’s Algorithm 6. 7 Deadlock Prevention Operating Systems 1

Deadlocks • Informal definition: Process is blocked on resource that will never be released. • Deadlocks waste resources • Deadlocks are rare: – Many systems ignore them • Resolved by explicit user intervention – Critical in many real-time applications • May cause damage, endanger life Operating Systems 2

Reusable/Consumable Resources • Reusable Resources – Examples: memory, devices, files, tables – Number of units is constant – Unit is either free or allocated; no sharing – Process requests, acquires, releases units • Consumable Resources – Examples: messages, signals – Number of units varies at runtime – Process releases (create) units (w/o acquire) – Other process requests and acquires (consumes) Operating Systems 3

Examples of Deadlocks p 1: . . . p 2: . . . open(f 1, w); open(f 2, w); open(f 1, w); . . . • Deadlock when executed concurrently p 1: if (C) send(p 2, m); p 2: . . . while(1) {. . . recv(p 2, m); recv(p 1, m); send(p 2, m); send(p 1, m); . . . } • Deadlock when C not true Operating Systems 4

Approaches to Deadlock Problem 1. Detection and Recovery – Allow deadlock to happen and eliminate it 2. Avoidance (dynamic) – Runtime checks disallow allocations that might lead to deadlocks 3. Prevention (static) – Restrict type of request and acquisition to make deadlock impossible Operating Systems 5

System Model (reusable only) • Resource graph: – represents processes, resources, and their interactions – Process = Circle – Resource = Rectangle with small circles for each unit – Request = Edge from process to resource class – Allocation = Edge from resource unit to process Operating Systems 6

System Model: State Transitions • Request: Create new request edge pi Rj Preconditions: – pi has no outstanding requests (= not blocked) – number of edges between pi and Rj cannot exceed total units of Rj • Acquisition: Reverse the request edge to pi Rj Precondition: – All requests of pi are satisfiable (simplifies model) • Release: Remove edge pi Rj Operating Systems 7

System Model: State Transitions • Resource graph represents current state of the system (snapshot) • Every request, acquisition, and release moves the system from one state to another Operating Systems 8

System Model – more definitions • A process is blocked in state S if it cannot request, acquire, or release any resource. • A process is deadlocked in state S if it is currently blocked now and remains blocked in all states reachable from state S • A state is a deadlock state if it contains a deadlocked process. • State S is a safe state if no deadlock state can be reached from S by any sequence of request, acquire, release operations. Operating Systems 9

Example Assume: 2 processes p 1, p 2; 2 resources R 1, R 2, • p 1 and p 2 both need R 1 and R 2 • p 1 always requests R 1 first, p 2 always requests R 2 first • Consider transition by p 1 only Operating Systems 10

Example • p 1 and p 2 both need R 1 and R 2 • p 1 requests R 1 before R 2 releases R 2 before R 1 • p 2 requests R 2 before R 1 releases R 1 before R 2 • consider all possible transitions Operating Systems 11

Deadlock Detection • Graph Reduction: Repeat the following 1. Select unblocked process p 2. Remove p and all request and allocation edges • Deadlock Graph not completely reducible. • All reduction sequences lead to the same result. Operating Systems 12

Special Cases of Detection • Testing for whether a specific process p is deadlocked: – Reduce until p is removed or graph irreducible • Continuous detection: 1. Current state not deadlocked 2. Next state T deadlocked only if: a. Operation was a request by p and b. p is deadlocked in T 3. Try to reduce T by p Operating Systems 13

Special Cases of Detection • Immediate allocations – All satisfiable requests are granted immediately – Expedient state: state with no satisfiable request edges – If all requests are granted immediately, all states are expedient. Example: not expedient (p 1 ->R 1) Operating Systems 14

Special Cases of Detection • Immediate allocations (continued) – Knot in expedient state Deadlock – Knot: A set K of nodes such that • Every node in K reachable from any other node in K • No outgoing edges from any node in K – Intuition: • All processes in K must have outstanding requests • Expedient state means requests not satisfiable • Therefore all processes are blocked – But condition is not sufficient for deadlock – not very useful Operating Systems 15

Special Cases of Detection • For single-unit resources, cycle deadlock • Intuition: – Cycle: must alternate p and R nodes – Every pi on cycle must have a request edge to Ri – Every Ri must have an allocation edge to pi+1 – no R is available (single unit) and thus all p’s are blocked Operating Systems 16

Recovery from Deadlock • Process termination – Kill all processes involved in deadlock; or – Kill one at a time. In what order? • by priority: consistent with scheduling • by cost of restart: length of recomputation • by impact on other processes: CS, producer/consumer • Resource preemption – Direct: Temporarily remove resource (e. g. , Memory) – Indirect: Rollback to earlier “checkpoint” Operating Systems 17

Dynamic Deadlock Avoidance Maximum Claim Graph • Process indicates maximum resources needed • Potential request edge pi Rj (dashed) • May turn into real request edge Operating Systems 18

Dynamic Deadlock Avoidance • Theorem: Prevent acquisitions that do not produce a completely reducible graph All state are safe. • Banker’s algorithm (Dijkstra): – Given a satisfiable request, p R, tentatively grant request, changing p R to R p – Try to reduce new claim graph – If completely reducible proceed. If not, reverse acquisition R p back to p R Operating Systems 19

Example of banker’s algorithm a. Which requests for R 1 can safely be granted? b. p 1: grant, resulting claim graph is reducible (p 1, p 3, p 2) c. p 2: do not grant, resulting claim graph is not reducible • p 3: grant, resulting claim graph is reducible (p 3, p 1/p 2) Operating Systems 20

Dynamic Deadlock Avoidance • Special Case: Single-unit resources a. Check for cycles after tentative acquisition Disallow if cycle is found, e. g. , grant R 1 to p 2? b. If claim graph contains no undirected cycles, all states are safe (no directed cycle can ever be formed) Operating Systems 21

Deadlock Prevention • Deadlock requires the following 3 conditions: 1. Mutual exclusion: • Resources not sharable 2. Hold and wait: • Process must be holding one resource while requesting another 3. Circular wait: • At least 2 processes must be blocked on each other Operating Systems 22

Deadlock Prevention 1. Eliminate mutual exclusion – Not possible in most cases – Spooling makes I/O devices sharable 2. Eliminate hold-and-wait – Request all resources at once – Release all resources before a new request – Release all resources if current request blocks 3. Eliminate circular wait – Order all resources – Process must request in ascending order Operating Systems 23