Deadlock (1) Dave Eckhardt Brian Railing Dave
TF
Published · 67 slides · 0 views
1 / 1
Description
Deadlock (1) Dave Eckhardt Brian Railing Dave OHallaron Roger Dannenberg Bruce Maggs Geoff Langdale L11Deadlock Debugging Reminder We cant really help with queries like: We did x... then something strange happened... ...can you tell us
Related Topics
Share
Embed code
Download this presentation From Below
"Deadlock (1) Dave Eckhardt Brian Railing Dave" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
01
Deadlock (1) Dave Eckhardt
Brian Railing
Dave O'Hallaron
Roger Dannenberg
Bruce Maggs
Geoff Langdale L11_Deadlock<br>
Brian Railing
Dave O'Hallaron
Roger Dannenberg
Bruce Maggs
Geoff Langdale L11_Deadlock<br>
02
Debugging Reminder We can't really help with queries like:
We did x... then something strange happened...
...can you tell us why?
You need to progress beyond “something happened”
What happened, exactly?
printf() is not always the right tool
output correct only if run-time environment is right
captures only what you told it to, only “C-level” stuff
changes your code by its mere presence!!!
We're serious about examining register dumps!
Overall, maybe re-read “Debugging” lecture notes<br>
We did x... then something strange happened...
...can you tell us why?
You need to progress beyond “something happened”
What happened, exactly?
printf() is not always the right tool
output correct only if run-time environment is right
captures only what you told it to, only “C-level” stuff
changes your code by its mere presence!!!
We're serious about examining register dumps!
Overall, maybe re-read “Debugging” lecture notes<br>
03
Synchronization – P2 You should really have, by Today:
Drawn pictures of thread stacks (even if not perfect)
Figured out where stubs belong, why
Made some system calls
Designed mutexes & condition variables
Wednesday:
Coded mutexes and condition variables
Thoughtful design for thr_create(), maybe thr_join()
Some code for thr_create(), and some “experience”
The startle test running<br>
Drawn pictures of thread stacks (even if not perfect)
Figured out where stubs belong, why
Made some system calls
Designed mutexes & condition variables
Wednesday:
Coded mutexes and condition variables
Thoughtful design for thr_create(), maybe thr_join()
Some code for thr_create(), and some “experience”
The startle test running<br>
04
Outline Process resource graph
What is deadlock?
Deadlock prevention
Next time
Deadlock avoidance
Deadlock recovery<br>
What is deadlock?
Deadlock prevention
Next time
Deadlock avoidance
Deadlock recovery<br>
05
Tape Drives A word on “tape drives”
Ancient computer resources
Access is sequential, read/write
Any tape can be mounted on any drive
One tape at a time is mounted on a drive
Doesn't make sense for multiple processes to simultaneously access a drive
Reading/writing a tape takes a while
Think “CD burner”... IBM 3420 (1970-1987)
www.ibm.com/ibm/history
Not for publication Data General 6023
wps.com/NOVA4<br>
Ancient computer resources
Access is sequential, read/write
Any tape can be mounted on any drive
One tape at a time is mounted on a drive
Doesn't make sense for multiple processes to simultaneously access a drive
Reading/writing a tape takes a while
Think “CD burner”... IBM 3420 (1970-1987)
www.ibm.com/ibm/history
Not for publication Data General 6023
wps.com/NOVA4<br>
06
Process/Resource graph<br>
07
Process/Resource graph<br>
08
Waiting<br>
09
Release<br>
10
Reallocation<br>
11
Multi-instance Resources<br>
12
Definition of Deadlock A deadlock
Set of N processes
Each waiting for an event
...which can be caused only by another process in the set
Every process will wait forever<br>
Set of N processes
Each waiting for an event
...which can be caused only by another process in the set
Every process will wait forever<br>
13
Deadlock Examples Simplest form
Process 1 owns printer, wants tape drive
Process 2 owns tape drive, wants printer
Less-obvious
Three tape drives
Three processes
Each has one tape drive
Each wants “just” one more
Can't blame anybody, but problem is still there<br>
Process 1 owns printer, wants tape drive
Process 2 owns tape drive, wants printer
Less-obvious
Three tape drives
Three processes
Each has one tape drive
Each wants “just” one more
Can't blame anybody, but problem is still there<br>
14
Deadlock Requirements Mutual Exclusion
Hold & Wait
No Preemption
Circular Wait<br>
Hold & Wait
No Preemption
Circular Wait<br>
15
Mutual Exclusion Resources aren't “thread-safe” (“reentrant”)
Must be allocated to one process/thread at a time
Can't be shared
Programmable Interrupt Timer
Can't have a different reload value for each process<br>
Must be allocated to one process/thread at a time
Can't be shared
Programmable Interrupt Timer
Can't have a different reload value for each process<br>
16
Hold & Wait Process holds some resources while waiting for more
mutex_lock(&m1);
mutex_lock(&m2);
mutex_lock(&m3);
This locking behavior is typical<br>
mutex_lock(&m1);
mutex_lock(&m2);
mutex_lock(&m3);
This locking behavior is typical<br>
17
No Preemption Can't force a process to give up a resource
Interrupting a CD-R burn creates a “coaster”
So don't do that
Obvious solution
CD-R device driver forbids second simultaneous open()
If you can't open it, you can't pre-empt it...<br>
Interrupting a CD-R burn creates a “coaster”
So don't do that
Obvious solution
CD-R device driver forbids second simultaneous open()
If you can't open it, you can't pre-empt it...<br>
18
Circular Wait Process 0 needs something process 4 has
Process 4 needs something process 7 has
Process 7 needs something process 1 has
Process 1 needs something process 0 has – uh-oh...
Described as “cycle in the resource graph”<br>
Process 4 needs something process 7 has
Process 7 needs something process 1 has
Process 1 needs something process 0 has – uh-oh...
Described as “cycle in the resource graph”<br>
19
Cycle in Resource Graph<br>
20
Deadlock Requirements Mutual Exclusion
Hold & Wait
No Preemption
Circular Wait
Each deadlock requires all four<br>
Hold & Wait
No Preemption
Circular Wait
Each deadlock requires all four<br>
21
Multi-Instance Cycle<br>
22
Multi-Instance Cycle (With Rescuer!)<br>
23
Cycle Broken<br>
24
Dining Philosophers The scene
410 staff members at a Chinese restaurant
A little short on utensils<br>
410 staff members at a Chinese restaurant
A little short on utensils<br>
25
Dining Philosophers<br>
26
Dining Philosophers Processes
5, one per person
Resources
5 bowls (dedicated to a diner: no contention: ignore)
5 chopsticks (1 between every adjacent pair of diners)
Contrived example?
Illustrates contention, starvation, deadlock<br>
5, one per person
Resources
5 bowls (dedicated to a diner: no contention: ignore)
5 chopsticks (1 between every adjacent pair of diners)
Contrived example?
Illustrates contention, starvation, deadlock<br>
27
Dining Philosophers A simple rule for eating
Wait until the chopstick to your right is free; take it
Wait until the chopstick to your left is free; take it
Eat for a while
Put chopsticks back down<br>
Wait until the chopstick to your right is free; take it
Wait until the chopstick to your left is free; take it
Eat for a while
Put chopsticks back down<br>
28
Dining Philosophers Deadlock Everybody reaches right...
...at the same time?<br>
...at the same time?<br>
29
Reaching Right<br>
30
Successful Acquisition<br>
31
Deadlock!<br>
32
Dining Philosophers – State int stick[5] = { -1 }; /* owner */
condition avail[5]; /* newly avail. */
mutex table = { available };
/* Right-handed convention */
right = diner; /* 3 ⇒ 3 */
left = (diner + 4) % 5; /* 3 ⇒ 7 ⇒ 2 */<br>
condition avail[5]; /* newly avail. */
mutex table = { available };
/* Right-handed convention */
right = diner; /* 3 ⇒ 3 */
left = (diner + 4) % 5; /* 3 ⇒ 7 ⇒ 2 */<br>
33
start_eating(int diner) mutex_lock(table);
while (stick[right] != -1)
condition_wait(avail[right], table);
stick[right] = diner;
while (stick[left] != -1)
condition_wait(avail[left], table);
stick[left] = diner;
mutex_unlock(table);<br>
while (stick[right] != -1)
condition_wait(avail[right], table);
stick[right] = diner;
while (stick[left] != -1)
condition_wait(avail[left], table);
stick[left] = diner;
mutex_unlock(table);<br>
34
done_eating(int diner) mutex_lock(table);
stick[left] = stick[right] = -1;
condition_signal(avail[right]);
condition_signal(avail[left]);
mutex_unlock(table);<br>
stick[left] = stick[right] = -1;
condition_signal(avail[right]);
condition_signal(avail[left]);
mutex_unlock(table);<br>
35
Can We Deadlock? At first glance the table mutex protects us
Can't have “everybody reaching right at same time”...
...mutex means only one person can access table...
...so allows only one reach at the same time, right?<br>
Can't have “everybody reaching right at same time”...
...mutex means only one person can access table...
...so allows only one reach at the same time, right?<br>
36
Can We Deadlock? At first glance the table mutex protects us
Can't have “everybody reaching right at same time”...
...mutex means only one person can access table...
...so allows only one reach at the same time, right?
Maybe we can!
condition_wait() is a “reach”
Can everybody end up in condition_wait()?<br>
Can't have “everybody reaching right at same time”...
...mutex means only one person can access table...
...so allows only one reach at the same time, right?
Maybe we can!
condition_wait() is a “reach”
Can everybody end up in condition_wait()?<br>
37
First diner gets both chopsticks<br>
38
Next gets right, waits on left<br>
39
Next two get right, wait on left<br>
40
Last waits on right<br>
41
First diner stops eating - briefly<br>
42
First diner stops eating - briefly signal()<br>
43
Next Step – One Possibility “Natural” –
longest-waiting diner progresses <br>
longest-waiting diner progresses <br>
44
Next Step – Another Possibility Or –
somebody else! <br>
somebody else! <br>
45
Last diner gets right, waits on left<br>
46
First diner gets right, waits on left<br>
47
Now things get boring<br>
48
Deadlock - What to do? Prevention
Avoidance
Detection/Recovery
Just reboot when it gets “too quiet”<br>
Avoidance
Detection/Recovery
Just reboot when it gets “too quiet”<br>
49
1: Prevention Restrict behavior or resources
Find a way to violate one of the 4 conditions
To wit...?
What we will talk about today
4 conditions, 4 possible ways<br>
Find a way to violate one of the 4 conditions
To wit...?
What we will talk about today
4 conditions, 4 possible ways<br>
50
2: Avoidance Processes pre-declare usage patterns
Dynamically examine requests
Imagine what other processes could ask for
Keep system in “safe state”<br>
Dynamically examine requests
Imagine what other processes could ask for
Keep system in “safe state”<br>
51
3: Detection/Recovery Maybe deadlock won't happen today...
...Hmm, it seems quiet...
...Oops, here is a cycle...
Abort some process
Ouch!<br>
...Hmm, it seems quiet...
...Oops, here is a cycle...
Abort some process
Ouch!<br>
52
4: Reboot When It Gets “Too Quiet” Which systems would be so simplistic?<br>
53
Four Ways to Forgiveness Each deadlock requires all four
Mutual Exclusion
Hold & Wait
No Preemption
Circular Wait
“Deadlock Prevention” - this is a technical term
Pass a law against one (pick one)
Deadlock happens only if somebody transgresses!<br>
Mutual Exclusion
Hold & Wait
No Preemption
Circular Wait
“Deadlock Prevention” - this is a technical term
Pass a law against one (pick one)
Deadlock happens only if somebody transgresses!<br>
54
Outlaw Mutual Exclusion? Approach: ban single-user resources
Require all resources to “work in shared mode”
Problem
Chopsticks???
Many resources don't work that way<br>
Require all resources to “work in shared mode”
Problem
Chopsticks???
Many resources don't work that way<br>
55
Outlaw Hold&Wait? Acquire resources all-or-none
start_eating(int diner)
mutex_lock(table);
while (1)
if (stick[lt] == stick[rt] == -1)
stick[lt] = stick[rt] = diner
mutex_unlock(table)
return;
condition_wait(released, table);<br>
start_eating(int diner)
mutex_lock(table);
while (1)
if (stick[lt] == stick[rt] == -1)
stick[lt] = stick[rt] = diner
mutex_unlock(table)
return;
condition_wait(released, table);<br>
56
Problems “Starvation”
Larger resource set makes grabbing everything harder
No guarantee a diner eats in bounded time
Low utilization
Larger peak resource needs hurts whole system always
Must allocate 2 chopsticks (and waiter!)
Nobody else can use waiter while you eat<br>
Larger resource set makes grabbing everything harder
No guarantee a diner eats in bounded time
Low utilization
Larger peak resource needs hurts whole system always
Must allocate 2 chopsticks (and waiter!)
Nobody else can use waiter while you eat<br>
57
Outlaw Non-preemption? Steal resources from sleeping processes!
start_eating(int diner)
right = diner; rright = (diner+1)%5;
mutex_lock(table);
while (1)
if (stick[right] == -1)
stick[right] = diner
else if (stick[rright] != rright)
/* right person can't be eating: take! */
stick[right] = diner;
...same for left...wait() if must...
mutex_unlock(table);<br>
start_eating(int diner)
right = diner; rright = (diner+1)%5;
mutex_lock(table);
while (1)
if (stick[right] == -1)
stick[right] = diner
else if (stick[rright] != rright)
/* right person can't be eating: take! */
stick[right] = diner;
...same for left...wait() if must...
mutex_unlock(table);<br>
58
Problem Some resources cannot be cleanly preempted
CD burner<br>
CD burner<br>
59
Outlaw Circular Wait? Impose total order on all resources
Require acquisition in strictly increasing order
Static order may work: allocate memory, then files
Dynamic – may need to “start over” sometimes
Traversing a graph
lock(4), visit(4) /* 4 has an edge to 13 */
lock(13), visit(13) /* 13 has an edge to 0 */
lock(0)?
Nope!
unlock(4), unlock(13)
lock(0), lock(4), lock(13), ...<br>
Require acquisition in strictly increasing order
Static order may work: allocate memory, then files
Dynamic – may need to “start over” sometimes
Traversing a graph
lock(4), visit(4) /* 4 has an edge to 13 */
lock(13), visit(13) /* 13 has an edge to 0 */
lock(0)?
Nope!
unlock(4), unlock(13)
lock(0), lock(4), lock(13), ...<br>
60
Assigning Diners a Total Order Lock order: 4, 3, 2, 1, 0 ≡ right chopstick, then left
Diner 4 ⇒ lock(4); lock(3);
Diner 3 ⇒ lock(3); lock(2);<br>
Diner 4 ⇒ lock(4); lock(3);
Diner 3 ⇒ lock(3); lock(2);<br>
61
Assigning Diners a Total Order Lock order: 4, 3, 2, 1, 0 ≡ right chopstick, then left
Diner 4 ⇒ lock(4); lock(3);
Diner 3 ⇒ lock(3); lock(2);
Diner 0 ⇒ lock(0); lock(4); /* violates lock order! */
Requires special-case locking code to get order right
if diner == 0
right = (diner + 4) % 5;
left = diner;
else
right = diner;
left = (diner + 4) % 5;
...<br>
Diner 4 ⇒ lock(4); lock(3);
Diner 3 ⇒ lock(3); lock(2);
Diner 0 ⇒ lock(0); lock(4); /* violates lock order! */
Requires special-case locking code to get order right
if diner == 0
right = (diner + 4) % 5;
left = diner;
else
right = diner;
left = (diner + 4) % 5;
...<br>
62
Problem May not be possible to force allocation order
Some trains go east, some go west<br>
Some trains go east, some go west<br>
63
Deadlock Prevention problems Typical resources require mutual exclusion
All-at-once allocation can be painful
Hurts efficiency
May starve
Resource needs may be unpredictable
Preemption may be impossible
Or may lead to starvation
Ordering restrictions may be impractical<br>
All-at-once allocation can be painful
Hurts efficiency
May starve
Resource needs may be unpredictable
Preemption may be impossible
Or may lead to starvation
Ordering restrictions may be impractical<br>
64
Deadlock Prevention Pass a law against one of the four ingredients
Great if you can find a tolerable approach
Very tempting to just let processes try their luck<br>
Great if you can find a tolerable approach
Very tempting to just let processes try their luck<br>
65
Deadlock is not... ...a simple synchronization bug
Deadlock remains even when those are cleaned up
Deadlock is a resource usage design problem
...the same as starvation
Deadlocked processes don't ever get resources
Starved processes don't ever get resources
Deadlock is a “progress” problem; starvation is a “bounded waiting” problem
....that “after-you, sir” dance in the corridor
That's “livelock” – continuous changes of state without forward progress<br>
Deadlock remains even when those are cleaned up
Deadlock is a resource usage design problem
...the same as starvation
Deadlocked processes don't ever get resources
Starved processes don't ever get resources
Deadlock is a “progress” problem; starvation is a “bounded waiting” problem
....that “after-you, sir” dance in the corridor
That's “livelock” – continuous changes of state without forward progress<br>
66
Next Time Deadlock Avoidance
Deadlock Recovery<br>
Deadlock Recovery<br>
67
Synchronization – Readings Next three lectures
OSC – Deadlock: 6.5.3, 6.6.3, Chapter 7
OS:P+P – Advanced Synchronization: Chapter 6
Reading ahead
Virtual Memory
Scheduling<br>
OSC – Deadlock: 6.5.3, 6.6.3, Chapter 7
OS:P+P – Advanced Synchronization: Chapter 6
Reading ahead
Virtual Memory
Scheduling<br>
68
Synchronization - P2 Reminder - P2 Q&A day
Can be Friday – if you bring enough hard questions
Otherwise Monday<br>
Can be Friday – if you bring enough hard questions
Otherwise Monday<br>
69
Synchronization – P2 You should really have, today:
Drawn pictures of thread stacks (even if not perfect)
Figured out where stubs belong, why
Made some system calls
Designed mutexes & condition variables
Wednesday:
Coded mutexes and condition variables
Thoughtful design for thr_create(), maybe thr_join()
Some code for thr_create(), and some “experience”
The startle test running<br>
Drawn pictures of thread stacks (even if not perfect)
Figured out where stubs belong, why
Made some system calls
Designed mutexes & condition variables
Wednesday:
Coded mutexes and condition variables
Thoughtful design for thr_create(), maybe thr_join()
Some code for thr_create(), and some “experience”
The startle test running<br>
70
Synchronization – P2 You should really have
Figured out where wrappers belong, why
Made some system calls
Designed mutexes & condition variables
Drawn pictures of thread stacks (even if not perfect)
Mutexes and condition variables nearly coded
By “the end of the day” you should have
Thoughtful design for thr_create(), maybe thr_join()
Some code for thr_create(), and some “experience”
The startle test running, or at least nearly running<br>
Figured out where wrappers belong, why
Made some system calls
Designed mutexes & condition variables
Drawn pictures of thread stacks (even if not perfect)
Mutexes and condition variables nearly coded
By “the end of the day” you should have
Thoughtful design for thr_create(), maybe thr_join()
Some code for thr_create(), and some “experience”
The startle test running, or at least nearly running<br>
71
Travel Advisory Exam is upcoming...
Soon we will begin an exam-conflict process; when you receive mail, please act on it right away
That week and the week after are popular dates for mid-term exams in many classes
If you provide a recruiter with a list of “blackout” dates, that person should schedule around that list
Computing such a list is a good idea<br>
Soon we will begin an exam-conflict process; when you receive mail, please act on it right away
That week and the week after are popular dates for mid-term exams in many classes
If you provide a recruiter with a list of “blackout” dates, that person should schedule around that list
Computing such a list is a good idea<br>
72
Travel Advisory Expect the angry “you haven’t declared your midterm exam conflict email” very soon
If you have a “class” conflict, you will need to clarify<br>
If you have a “class” conflict, you will need to clarify<br>