CPS110: Deadlock Landon Cox February 5, 2008

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

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

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

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?

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?

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

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?

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

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

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

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

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.”

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

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

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

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).

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.

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

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

Dining philosophers B B A A C C D D E E 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

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)

Dining philosophers B B A A C C D D E E 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)

Deadlock avoidance  Issue with imposing global orderings  Must change the application  Common technique  Requires programming discipline

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!

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

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

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

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

Example  Bank  Has $6000 to loan  Customers  Establish credit limits (max resources)  Borrow money (up to their limit)  Return all money at the end

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)

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)

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

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

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

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

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”)