© 2019 Ethan L.

Miller

Progress Space (≥2 Tasks)

Progress
of T2

Joint Progress Path

Using Resource 1

Infeasible
Region

Progress of T1

Using Resource 1

CSE 130: Principles of Computer System Design (Fall 2019) 1

 © 2019 Ethan L. Miller

Two Resources

Progress
of T2
Using R2

Infeasible
Region
Using R1

Infeasible
Region

Progress of T1

Using R1

Using R2

CSE 130: Principles of Computer System Design (Fall 2019) 2

 © 2019 Ethan L. Miller

Two Resources

Progress
of T2

Joint Progress Path

Using R2

Infeasible
Region
Using R1

Progress of T1

Using R1

Using R2

CSE 130: Principles of Computer System Design (Fall 2019) 3

 © 2019 Ethan L. Miller

Two Resources

Progress
of T2
Using R2

Infeasible
Joint
Region
Using R1

Progress
Path

Progress of T1

Using R1

Using R2

CSE 130: Principles of Computer System Design (Fall 2019) 4

 © 2019 Ethan L. Miller

Unsafe Region

Progress
of T2 ❖ Why is this a problem?
‣ T1 has R2
‣ T2 has R1
‣ Both will want R1 & R2
Using R2

Infeasible ❖ Irreversibility of progress

Region
Joint guarantees eventual
Using R1

Progress
Unsafe
Path
Region
deadlock

Progress of T1

Using R1

Using R2

CSE 130: Principles of Computer System Design (Fall 2019) 5

 © 2019 Ethan L. Miller

Necessary conditions for an Unsafe Region to exist

Progress
of T2
‣ Tasks claim exclusive control
over a resource
• Mutual Exclusion
‣ Resource cannot be taken away
• Nonpreemption
‣ Tasks hold resources while
Using R2

Infeasible
Region waiting
Joint
• Hold and Wait
Using R1

Progress
Unsafe
Path
Region

Progress of T1

Using R1

Using R2

CSE 130: Principles of Computer System Design (Fall 2019) 6

 © 2019 Ethan L. Miller

Necessary conditions for an Unsafe Region to exist

Progress
of T2
‣ Tasks claim exclusive control
over a resource
• Mutual Exclusion
‣ Resource cannot be taken away
• Nonpreemption
‣ Tasks hold resources while
Using R2

Infeasible
Region waiting
Joint
• Hold and Wait
Using R1

Progress
Unsafe
Path
Region

Progress of T1

Using R1

Using R2

CSE 130: Principles of Computer System Design (Fall 2019) 7

 © 2019 Ethan L. Miller

Dining Philosophers
❖ N philosophers around a table
‣ All are hungry
‣ All like to think
❖ N chopsticks available
‣ 1 between each pair of philosophers
❖ Philosophers need two chopsticks to
eat
❖ Philosophers alternate between eating
and thinking
❖ Goal: coordinate use of chopsticks

CSE 130: Principles of Computer System Design (Fall 2019) 8

 © 2019 Ethan L. Miller

Dining Philosophers: solution 1

❖ Use a semaphore for each
Shared variables
chopstick
const int32_t n;
❖ A hungry philosopher // initialize to 1
Semaphore chopstick[n];
‣ Gets the chopstick to his right
‣ Gets the chopstick to his left
‣ Eats Code for philosopher i

‣ Puts down the chopsticks while (1) {

chopstick[i].down();
❖ Potential problems? chopstick[(i+1)%n].down();

‣ Deadlock // eat
chopstick[i].up();
‣ Fairness chopstick[(i+1)%n].up();
// think
}

CSE 130: Principles of Computer System Design (Fall 2019) 9

 © 2019 Ethan L. Miller

Dining Philosophers
❖ All philosophers grab the chopstick on
their right and wait for the chopstick
on their left to be released

CSE 130: Principles of Computer System Design (Fall 2019) 10

 © 2019 Ethan L. Miller

Dining Philosophers
❖ All philosophers grab the chopstick on
their right and wait for the chopstick
on their left to be released
❖ How to detect deadlock?

‣ Use a graph
• Vertex per resource (chopstick)
• Directed edge per task
- “Tail” indicates held resource

- “Arrowhead” indicates
requested resource Not Task → Resource Edge
CSE 130: Principles of Computer System Design (Fall 2019) 11
 © 2019 Ethan L. Miller

Cycle Indicates Deadlock

❖ All philosophers grab the chopstick on
their right and wait for the chopstick
on their left to be released
❖ How to detect deadlock?

‣ Use a graph
• Vertex per resource (chopstick)
• Directed edge per task
- “Tail” indicates held resource

If deadlock exists then a cycle exists.

Exactly 1 resource of each type?
- “Arrowhead” indicates Then cycle implies a deadlock.
requested resource
CSE 130: Principles of Computer System Design (Fall 2019) 12
 © 2019 Ethan L. Miller

Dining Philosophers: solution 2

❖ Use a semaphore for each chopstick Code for philosopher i
❖ A hungry philosopher
int32_t i1,i2;
‣ Gets lower, then higher numbered while (1) {
chopstick if (i != (n-1)) {
‣ Eats i1 = i;
i2 = i+1;
‣ Puts down the chopsticks } else {
i1 = 0;
❖ Potential problems? i2 = n-1;
‣ Deadlock }
‣ Fairness chopstick[i1].down();
chopstick[i2].down();
// eat
Shared variables chopstick[i1].up();
chopstick[i2].up();
const int32_t n; // think
// initialize to 1 }
Semaphore chopstick[n];
CSE 130: Principles of Computer System Design (Fall 2019) 13
 © 2019 Ethan L. Miller

No Cycle – No Deadlock
❖ All philosophers grab the chopstick
with the lowest index
❖ How to detect deadlock? 1
0
‣ Use a graph
• Vertex per resource (chopstick) 2
• Directed edge per task
5
- “Tail” indicates held resource

4 3

- “Arrowhead” indicates If deadlock exists then a cycle exists.

requested resource Exactly 1 resource of each type?
Then cycle implies a deadlock.
CSE 130: Principles of Computer System Design (Fall 2019) 14
 © 2019 Ethan L. Miller

Illegal Graph
❖ All philosophers grab the chopstick
with the lowest index
❖ How to detect deadlock? 1
0
‣ Use a graph
• Vertex per resource (chopstick) 2
• Directed edge per task
5
- “Tail” indicates held resource

4 3

Illegal state: Two tasks cannot hold the

same resource at the same time.

CSE 130: Principles of Computer System Design (Fall 2019) 15

 © 2019 Ethan L. Miller

Dining philosophers with locks

Shared variables Code for philosopher j

const int32_t n; while (1) {
// initialize to THINK // pickup chopstick
int32_t state[n]; mutex.Acquire();
Lock mutex; state[j] = HUNGRY;
// use mutex for self test(j);
Condition self[n]; if (state[j] != EAT)
self[j].Wait();
void test(int32_t k) mutex.Release();
{ // eat
if ((state[(k+n-1)%n)]!=EAT) && mutex.Acquire();
(state[k]==HUNGRY) && state[j] = THINK;
(state[(k+1)%n]!=EAT)) { test((j+1)%n); // next
state[k] = EAT; test((j+n-1)%n); // prev
self[k].Signal(); mutex.Release();
} // think
} }

CSE 130: Principles of Computer System Design (Fall 2019) 16

 © 2019 Ethan L. Miller

Deadlocks, in other words

❖ Deadlocks occur when …
‣ Processes are granted exclusive
access to devices or software Process 1 Process 2
constructs (resources)
A
‣ Each deadlocked process needs a
resource held by another B
deadlocked process

A
B

DEADLOCK!

CSE 130: Principles of Computer System Design (Fall 2019) 17

 © 2019 Ethan L. Miller

What is a deadlock?
❖ Formal de nition:
“A set of processes is deadlocked if each process in the set is
waiting for an event that only another process in the set can cause.”

❖ Usually, the event is release of a currently-held resource

❖ In deadlock, none of the processes can

‣ Run
‣ Release resources
‣ Be awakened

CSE 130: Principles of Computer System Design (Fall 2019) 18

fi
 © 2019 Ethan L. Miller

Four conditions for deadlock

❖ Mutual exclusion
‣ Each resource is assigned to at most one process
❖ Hold and wait
‣ A process holding resources can request more resources
❖ No preemption
‣ Previously granted resources cannot be forcibly taken away
❖ Circular wait
‣ There must be a circular chain of 2 or more processes where each is waiting
for a resource held by the next member of the chain

CSE 130: Principles of Computer System Design (Fall 2019) 19

 © 2019 Ethan L. Miller

Dealing with deadlock

❖ How can the OS deal with deadlock?
‣ Ignore the problem altogether!
• Hopefully, it’ll never happen…
‣ Detect deadlock & recover from it
‣ Dynamically avoid deadlock
• Careful resource allocation
‣ Prevent deadlock
• Remove at least one of the four necessary conditions

❖ We’ll explore these tradeo s

CSE 130: Principles of Computer System Design (Fall 2019) 20

ff
 © 2019 Ethan L. Miller

The Ostrich Algorithm

❖ Pretend there’s no problem
❖ Reasonable if
‣ Deadlocks occur very rarely
‣ Cost of prevention is high

❖ UNIXTM and WindowsTM take this approach

‣ Resources (memory, CPU, disk space) are plentiful
‣ Deadlocks over such resources rarely occur
‣ Deadlocks typically handled by rebooting
❖ Trade o between convenience and correctness

CSE 130: Principles of Computer System Design (Fall 2019) 21

ff
 © 2019 Ethan L. Miller

Not getting into deadlock…

❖ Many situations may result in deadlock (but don’t have to)
‣ Can we get out of it?
❖ Find ways to:
‣ Detect deadlock and reverse it
‣ Stop it from happening in the rst place

CSE 130: Principles of Computer System Design (Fall 2019) 22

fi
 © 2019 Ethan L. Miller

Another Kind of Resource Allocation Graph

❖ Resource allocation modeled by
directed graphs
A B ❖ Example 1:
‣ Resource R assigned to process A
❖ Example 2:
R S
‣ Process B is requesting / waiting for
resource S
❖ Example 3:
T ‣ Process C holds T, waiting for U
‣ Process D holds U, waiting for T
C D
‣ C and D are in deadlock!

CSE 130: Principles of Computer System Design (Fall 2019) 23

 © 2019 Ethan L. Miller

Detecting deadlocks using graphs

❖ Process holdings and requests in the table and in the graph (they’re
equivalent)
❖ Graph contains a cycle deadlock!
‣ Easy to pick out by looking at it (in this case)
‣ Need to mechanically detect deadlock
❖ Not all processes are deadlocked (1, 3, 6 not in deadlock)

R 1 2
Process Holds Wants
1 R S
2 T 3 S 4 T 5
3 S
4 U S,T
6 U V
5 T V
6 W S
7 V U W 7

CSE 130: Principles of Computer System Design (Fall 2019) 24

 © 2019 Ethan L. Miller

Recovering from deadlock

❖ Recovery through preemption
‣ Take a resource from some other process
‣ Depends on nature of the resource and the process
❖ Recovery through rollback
‣ Checkpoint a process periodically
‣ Use saved state to restart the process if it’s in deadlock
‣ May present a problem if the process a ects lots of “external” things
❖ Recovery through killing processes
‣ Crudest but simplest way to break a deadlock: kill one of the processes in the
deadlock cycle
‣ Other processes can get its resources
‣ Try to choose a process that can be rerun from the start
• Pick one that hasn’t run too far already
CSE 130: Principles of Computer System Design (Fall 2019) 25
ff
 © 2019 Ethan L. Miller

Preventing deadlock
❖ Deadlock can be completely prevented!
❖ Ensure that at least one of the conditions for deadlock never occurs
‣ Mutual exclusion
‣ Circular wait
‣ Hold & wait
‣ No preemption
❖ Not always possible…

CSE 130: Principles of Computer System Design (Fall 2019) 26

 © 2019 Ethan L. Miller

Eliminating mutual exclusion

❖ Some devices (such as printer) can be spooled
‣ Only the printer daemon uses printer resource
‣ This eliminates deadlock for printer
❖ Not all devices can be spooled
❖ Principle:
‣ Avoid assigning resource when not absolutely necessary
‣ As few processes as possible actually claim the resource

CSE 130: Principles of Computer System Design (Fall 2019) 27

 © 2019 Ethan L. Miller

Attacking “hold and wait”

❖ Require processes to request resources before starting
‣ A process never has to wait for what it needs
❖ This can present problems
‣ A process may not know required resources at start of run
‣ This also ties up resources other processes could be using
• Processes will tend to be conservative and request resources they might need
❖ Variation: a process must give up all resources before making a new
request
‣ Process is then granted all prior resources as well as the new ones
‣ Problem: what if someone grabs the resources in the meantime—how can
the process save its state?

CSE 130: Principles of Computer System Design (Fall 2019) 28

 © 2019 Ethan L. Miller

Livelock
❖ Sometimes, processes can still run, but not make progress
❖ Example: two processes want to use resources A and B
‣ P0 gets A, P1 gets B
‣ Each realizes that a deadlock will occur if they proceed as planned!
‣ P0 drops A, P1 drops B
‣ P0 gets B, P1 gets A
‣ Same problem as before
‣ This can go on for a very long time...
❖ Real-world example: Ethernet transmission collisions
‣ If there’s a “collision” on the wire, wait and try again
‣ Multiple processes waited the exact same amount of time...

CSE 130: Principles of Computer System Design (Fall 2019) 29

 © 2019 Ethan L. Miller

Attacking “no preemption”

❖ This is not usually a viable
option
❖ Consider a process given the
printer
‣ Halfway through its job, take away
the printer
‣ Confusion ensues!
❖ May work for some resources
‣ Forcibly take away memory pages,
suspending the process
‣ Process may be able to resume with
no ill e ects

CSE 130: Principles of Computer System Design (Fall 2019) 30

ff
 © 2019 Ethan L. Miller

Attacking “circular wait”

❖ Assign an order to resources
❖ Always acquire resources in D

numerical order
‣ Need not acquire them all at once!
❖ Circular wait is prevented C

‣ A process holding resource n can’t 3 2

wait for resource m if m < n
‣ No way to complete a cycle! B
• Place processes above the highest 1
resource they hold and below any
they’re requesting
• All arrows point up! A

CSE 130: Principles of Computer System Design (Fall 2019) 31

 © 2019 Ethan L. Miller

Deadlock prevention: summary

Condition Prevented by

Mutual exclusion Spool everything

Hold and wait Request all resources initially

Take resources away if there’s not

No preemption
a complete set

Circular wait Order resources numerically

CSE 130: Principles of Computer System Design (Fall 2019) 32