Download presentation
Presentation is loading. Please wait.
Published byAngela Phelps Modified over 9 years ago
1
CPS110: Deadlock Landon Cox February 5, 2008
2
Concurrency so far Mostly tried to constrain orderings Locks, monitors, semaphores It is possible to over-constrain too A must run before B B must run before A This can lead to deadlock
3
Definitions Resource Thing needed by a thread to do its job Threads wait for resources E.g. locks, disk space, memory, CPU Deadlock Circular waiting for resources Leaves threads unable to make progress
4
Example deadlock Both CPS108 and CPS110 are full You want to switch from 110 to 108 Someone else wants to switch from 108 to 110 Algorithm for switching Wait for spot in new class to open up Add new class Drop old class Problem: must add before dropping
5
Deadlock and starvation Deadlock starvation Starvation = one process waits forever Thread AThread B lock (x)lock (y) lock (y)lock (x)… unlock (y)unlock(x) unlock (x)unlock(y) Can deadlock occur?
6
Deadlock and starvation Deadlock starvation Starvation = one process waits forever Thread AThread B lock (x) lock (y) lock (y) // wait for B lock (x) // wait for A Can deadlock occur?Will deadlock always occur?
7
Common thread work pattern Anyone taken CPS116 (databases)? This is called “two-phase” locking Ensures “conflict-serializability” Still deadlock-prone Phase 1. while (not done) { get some resources (block if necessary) work // assume finite } Phase 2. release all resources
8
Dining philosophers B B A A C C D D E E Philosopher algorithm 1) Wait for right chopstick 2) Pick up right chopstick 3) Wait for left chopstick 4) Pick up left chopstick 5) Eat 6) Put both chopsticks down How can deadlock occur?
9
Conditions for deadlock 1.Limited resource Not enough for all threads simultaneously 2.Hold-and-wait Hold one resource, while waiting for another 3.No pre-emption Cannot force threads to give up resources 4.Circular chain of requests
10
Circular chain of requests Arrows Thread resource it’s waiting for Resource thread that’s holding it Thread A Thread B Resource 2 Resource 1 Thread B acquires Resource 1 Thread B waits for Resource 2 Thread A acquires Resource 2 Thread A waits for Resource 1 Called a wait-for graph
11
Deadlock What should we do about them? 1.Ignore them Common OS-level solution for programs (OS has no control over user programs) 2.Detect-and-fix 3.Prevent
12
Detect-and-fix First part: detect This is easy; just scan the wait-for graph Second part: fix 1.Kill first thread, take back resources by force Why might this be unsafe? Can expose inconsistent state 2.Roll-back actions of 1 or more thread, retry Often used in databases Not always possible (some actions can’t be undone) E.g. can’t unsend a network message
13
Detect-and-fix Retrying during fix phase can be tricky If holding R and will wait for L, drop R and try again. B B A A C C D D E E What could happen? Everyone picks up R Everyone drops R Everyone picks up R Everyone drops R (and so on) This is called “livelock.”
14
Detect-and-fix Retrying during fix phase can be tricky If holding R and will wait for L, drop R and try again. B B A A C C D D E E How to prevent livelock? Choose a winner. How to choose a winner? First to start/pick up? What if we have priorities? (called “priority inversion”) e.g. Queen waiting for joker Should Queen always win? No, could starve the joker
15
Deadlock prevention Idea: remove one of four pre-conditions 1.Make resources unlimited Best solution, but often impossible Can still increase number, reduce likelihood (larger 108 and 110 classes) Not clear this works for locks
16
Deadlock prevention 2. Eliminate hold-and-wait Idea: move resource acquisition to beginning Two ways to avoid holding while waiting Phase 1a. get all resources Phase 1b. while (not done) { work // assume finite } Phase 2. release all resources
17
Eliminating hold-and-wait 1.Wait for everything to be free, then grab them all at once Philosopher algorithm lock while (left chopstick busy || right chopstick busy) { wait } pick up right chopstick pick up left chopstick unlock eat lock drop chopsticks unlock Any potential problems? Can induce starvation (neighbors alternate eating).
18
Eliminating hold-and-wait 2.If you find a resource busy, drop everything, and try again Philosopher algorithm lock while (1) { while (right chopstick busy) { wait } pick up right chopstick if (left chopstick busy) { drop right chopstick } else { pick up left chopstick break } unlock eat lock drop chopsticks unlock Issues? Must predict what you need in advance. Hold reservations longer than needed Requires changes to applications.
19
Deadlock prevention 3.Enable pre-emption Can pre-empt the CPU (context switch) Can pre-empt memory (swap to disk) Not everything can be pre-empted Can locks be pre-empted? Probably not Must ensure that data is in consistent state
20
Deadlock prevention 4. Eliminate circular chain of requests How can we get rid of these cycles? Impose an ordering on resource acquisition E.g. must always acquire A before B In dining philosophers? Number chopsticks Pick up lower-numbered chopstick first
21
Dining philosophers B B A A C C D D E E 1 1 2 2 3 3 4 5 5 Philosopher algorithm 1) Wait for lower chopstick 2) Pick up lower chopstick 3) Wait for higher chopstick 4) Pick up higher chopstick 5) Eat 6) Put both chopsticks down Try to create a deadlock
22
Universal ordering Why does this work? At some point in time T holds highest-numbered acquired resource T is guaranteed to make progress. Why? If T needs a higher-numbered resource, it must be free If T needs a lower-numbered resource, it already has it If T can make progress, it will eventually release all of its resources What if another thread acquires a higher-numbered resource? They just become T (in which case, the same reasoning as above holds)
23
Dining philosophers B B A A C C D D E E 1 1 2 2 3 3 4 5 5 Philosopher algorithm 1) Wait for lower chopstick 2) Pick up lower chopstick 3) Wait for higher chopstick 4) Pick up higher chopstick 5) Eat 6) Put both chopsticks down What if E only needs one chopstick? Only have trouble if E acquires lower- numbered chopstick before 5. (but this is a violation of our rule)
24
Deadlock avoidance Issue with imposing global orderings Must change the application Common technique Requires programming discipline
25
Course administration Project 1 Due February 21 st (~ two weeks) 3 groups are done with 1d Should be done with 1d by end of the week 1t is a lot more work, don’t keep putting it off!
26
Course administration Remember to work on your thread library test suite too For each of your test cases Compare output of your library with thread.o Writing test cases Read through spec Write test cases to stress each required part E.g. lock() blocks if lock is already held Use yield() to create the right interleavings Read through your code Write test cases to exercise all lines of code E.g. each clause of an if/else statement Micro-tests are better for debugging than macro-tests
27
Banker’s algorithm Like acquiring all resources first (but more efficient) Phase 1a. state max resources needed Phase 1b. while (not done) { get some resources (blocking if not SAFE) work // assume finite } Phase 2. release all resources
28
Comparing banker’s algorithm Original Acquired resources if available (deadlock) Previous solution (no “hold-and-wait”) Acquired all resources or none Must acquire max resources to do work All threads doing work own their max Thus, all threads doing work can complete
29
Banker’s algorithm Give out resources at request time (1b) Request granted if it is safe Can grant max requests of all threads in some sequential order Sequential order One thread gets its max resources, finishes, and releases its resources Another thread gets its max resources, finishes, and releases, etc Phase 1a. state max resources needed Phase 1b. while (not done) { get some resources (blocking if not SAFE) work // assume finite } Phase 2. release all resources
30
Example Bank Has $6000 to loan Customers Establish credit limits (max resources) Borrow money (up to their limit) Return all money at the end
31
Example: Solution 1 Bank gives money on request, if available For example Ann asks for credit line of $2000 Bob asks for credit line of $4000 Cat asks for credit line of $6000 Can bank approve each of these lines? (assuming it gives money, if available)
32
Example: Solution 1 No. Consider: Ann takes out $1000 (bank has $5000) Bob takes out $2000 (bank has $3000) Cat takes out $3000 (bank is empty) Bank has no money Ann, Bob, and Cat could all ask for $ None would be able to finish (deadlock)
33
Example: Solution 1 This only works if we wait to approve credit lines For example Ann asks for credit line of $2000 Bank approves Bob asks for credit line of $4000 Bank approves Cat asks for credit line of $6000 Bank must make Cat wait until Ann or Bob finish Sum of all max resource needs of all current threads Must not exceed the total resources
34
Example: Solution 2 Bank says ok to all credit line requests Customers may wait for resources Bank ensures no deadlocks For example Ann asks for credit limit of $2000 Bob asks for credit limit of $4000 Cat asks for credit limit of $6000 Bank approves all credit limits
35
Example: Solution 2 Ann takes out $1000 (bank has $5000) Bob takes out $2000 (bank has $3000) Cat wants to take out $2000 Is this allowed? Bank would be left with $1000 Ann would still be guaranteed to finish (could take out another $1000) On finish, bank would have $2k This is enough to ensure that Bob can finish
36
Example: Solution 2 Ann takes out $1000 (bank has $5000) Bob takes out $2000 (bank has $3000) Cat wants to take out $2500 Is this allowed? Bank would be left with $500 Can’t guarantee that any threads will finish
37
Banker’s algorithm Allows resources to be overcommitted How can we apply this to dining philosophers? Put all chopsticks in the middle of the table Max resource need for each philosopher is 2 Grant requests, unless There is only one chopstick left and nobody has 2 Nice algorithm, but no one uses it. Why? You rarely know what you’ll need in advance Doesn’t really make sense for locks (no “generic lock”)
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.