Principles of Operating Systems

CS 446/646 2. Processes
a. Process Description & Control b. Threads c. Concurrency d. Deadlocks
Deadlock principles: diagrams and graphs Deadlock prevention: changing the rules Deadlock avoidance: optimizing the allocation Deadlock detection: recovering after the facts

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

154

2.d Deadlocks
Deadlock principles: diagrams and graphs

A deadlock is a permanent blocking of a set of threads

a deadlock can happen while threads/processes are competing for system resources or communicating with each other there is no universal efficient solution against deadlocks

Illustration of a deadlock
2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes

Tanenbaum, A. S. (2001) Modern Operating Systems (2nd Edition).

155

2.d Deadlocks
Deadlock principles: diagrams and graphs

Illustration of a deadlock
two processes, P and Q, compete for two resources, A and B each process needs exclusive use of each resource Process P
A required

Process Q
... Get B ... Get A ... Release B ... Release A ...
Competing processes
B required

B required

... Get A ... Get B ... Release A ... Release B ...

A required

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

156

2.d Deadlocks
Deadlock principles: diagrams and graphs

Illustration of a deadlock scheduling path 1

Q executes everything before P can ever get A when P is ready, resources A and B are free and P can proceed Process P
A required

Process Q
... Get B ... Get A ... Release B ... Release A ...
Happy scheduling 1
B required

B required

... Get A ... Get B ... Release A ... Release B ...

A required

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

157

2.d Deadlocks
Deadlock principles: diagrams and graphs

Illustration of a deadlock scheduling path 2

Q gets B and A, then P is scheduled; P wants A but is blocked by As mutex; so Q resumes and releases B and A; P can now go Process P
A required

Process Q
... Get B ... Get A ... Release B ... Release A ...
Happy scheduling 2
B required

B required

... Get A ... Get B ... Release A ... Release B ...

A required

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

158

2.d Deadlocks
Deadlock principles: diagrams and graphs

Illustration of a deadlock scheduling path 3

Q gets only B, then P is scheduled and gets A; now both P and Q are blocked, each waiting for the other to release a resource Process P
A required

Process Q
... Get B ... Get A ... Release B ... Release A ...
B required

B required

... Get A ... Get B ... Release A ... Release B ...

deadlock

A required

Bad scheduling deadlock

2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes 159

2.d Deadlocks
Deadlock principles: diagrams and graphs

Stallings, W. (2004) Operating Systems: Internals and Design Principles (5th Edition).

Joint progress diagram

2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes 160

2.d Deadlocks
Deadlock principles: diagrams and graphs

Deadlocks depend on the program and the scheduling

program design the order of the statements in the code creates the landscape of the joint progress diagram this landscape may contain gray swamp areas leading to deadlock scheduling condition the interleaved dynamics of multiple executions traces a path in this landscape this path may sink in the swamps
2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes 161

2.d Deadlocks
Deadlock principles: diagrams and graphs

Changing the program changes the landscape

here, P releases A before getting B deadlocks between P and Q are not possible anymore Process P
A required

Process Q
... Get B ... Get A ... Release B ... Release A ...
Competing processes
B required

B required

... Get A ... Release A ... Get B ... Release B ...

A required

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

162

2.d Deadlocks
Deadlock principles: diagrams and graphs

no swamp area: there exists no path leading to deadlock

Joint progress diagram
2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes

Stallings, W. (2004) Operating Systems: Internals and Design Principles (5th Edition).

163

2.d Deadlocks
Deadlock principles: diagrams and graphs

Snapshot of concurrency: Resource Allocation Graph

a resource allocation graph is a directed graph that depicts a state of the system of resources and processes

Stallings, W. (2004) Operating Systems: Internals and Design Principles (5th Edition).

RAGs
2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes 164

2.d Deadlocks
Deadlock principles: diagrams and graphs

Resource allocation graphs & deadlocks

there is deadlock when a closed chain of processes exists each process holds at least one resource needed by the next process

Stallings, W. (2004) Operating Systems: Internals and Design Principles (5th Edition).

A deadlocks RAG
2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes 165

2.d Deadlocks
Deadlock principles: diagrams and graphs

Design conditions for deadlock (create the swamps)

1. mutual exclusion the design contains protected critical regions; only one process at a time may use these 2. hold & wait the design is such that, while inside a critical region, a process may have to wait for another critical region 3. no resource preemption there must not be any hardware or O/S mechanism forcibly removing a process from its CR

+ Scheduling condition for deadlock (go to the swamps)

4. circular wait two or more hold-&-waits are happening in a circle: each process holds a resource needed by the next

= Deadlock!
2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes 166

2.d Deadlocks
Deadlock principles: diagrams and graphs

Three strategies for dealing with deadlocks

deadlock prevention changing the rules one or several of the deadlock conditions 1., 2., 3. or 4. are removed a priori (design decision) deadlock avoidance optimizing the allocation deadlock conditions 1., 2., 3. are maintained but resource allocation follows extra cautionary rules (runtime decision) deadlock detection recovering after the facts no precautions are taken to avoid deadlocks, but the system cleans them periodically (deadlock collector)
2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes 167

2.d Deadlocks
Deadlock prevention: changing the rules

Remove one of the design or scheduling conditions?

remove mutual exclusion? not possible: must always be supported by the O/S remove hold & wait? require that a process gets all its resources at one time inefficient and impractical: defeats interleaving, creates long waits, cannot predict all resource needs remove no preemption = allow preemption? require that a process releases and requests again ok remove circular wait? ex: impose an ordering of resources inefficient, again
2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes 168

2.d Deadlocks
Deadlock avoidance: optimizing the allocation

Allow all conditions, but allocate wisely

given a resource allocation request, a decision is made dynamically whether granting this request can potentially lead to a deadlock or not do not start a process if its demands might lead to deadlock do not grant an incremental resource request to a running process if this allocation might lead to deadlock avoidance strategies requires knowledge of future process request (calculating chess moves ahead)

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

169

2.d Deadlocks
Deadlock avoidance: optimizing the allocation

Resource allocation denial: the banker's algorithm

at any time, the state of the system is the current allocation of multiple resources to multiple processes a safe state is where there is at least one sequence that does not result in deadlock an unsafe state is a state where there is no such sequence analogy = banker refusing to grant a loan if funds are too low to grant more loans + uncertainty about how long a customer will repay

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

170

2.d Deadlocks
Deadlock avoidance: optimizing the allocation

Resource allocation denial: the banker's algorithm

can a process run to completion with the available resources?

(a)

compare what is still needed with what is left

Stallings, W. (2004) Operating Systems: Internals and Design Principles (5th Edition).

(b) Determination of a safe state

2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes 171

2.d Deadlocks
Deadlock avoidance: optimizing the allocation

Resource allocation denial: the banker's algorithm

idea: refuse to allocate if it may result in deadlock

Stallings, W. (2004) Operating Systems: Internals and Design Principles (5th Edition).

(c)

(d) Determination of a safe state (cont'd)

2/28/2006 CS 446/646 - Principles of Operating Systems - 2. Processes

all could run to completion: thus, (a) was a safe state

172

2.d Deadlocks
Deadlock avoidance: optimizing the allocation

Resource allocation denial: the banker's algorithm

idea: refuse to allocate if it may result in deadlock

Stallings, W. (2004) Operating Systems: Internals and Design Principles (5th Edition).

(a) safe (a)

(b) unsafe
2/28/2006

potential for deadlock (we dont know how long Ri will be kept) thus, (b) is an unsafe state: Determination of an unsafe state dont allow (b) to CS 446/646 - Principles of Operating Systems - 2. Processes happen 173

2.d Deadlocks
Deadlock detection: recovering after the facts

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

174

Principles of Operating Systems

CS 446/646 2. Processes
a. Process Description & Control b. Threads c. Concurrency d. Deadlocks
Deadlock principles: diagrams and graphs Deadlock prevention: changing the rules Deadlock avoidance: optimizing the allocation Deadlock detection: recovering after the facts

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

175

Principles of Operating Systems

CS 446/646 2. Processes
a. Process Description & Control b. Threads c. Concurrency d. Deadlocks

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

176

Principles of Operating Systems

CS 446/646 0. Course Presentation 1. Introduction to Operating Systems 2. Processes 3. Memory Management 4. CPU Scheduling 5. Input/Output 6. File System 7. Case Studies

2/28/2006

CS 446/646 - Principles of Operating Systems - 2. Processes

177