A house of cards? Advanced Synchronization and Deadlock. Contra Threads: Events. Contra Threads: Events

Size: px

Start display at page:

Download "A house of cards? Advanced Synchronization and Deadlock. Contra Threads: Events. Contra Threads: Events"

Laurel McCoy
5 years ago
Views:

1 A house of cards? Advanced Synchronization and Deadlock Locks + CV/signal a great way to regulate access to a single shared object......but general multi-threaded programs touch multiple shared objects How can we atomically modify multiple objects to maintain Safety: prevent applications from seeing inconsistent states Liveness: avoid deadlock a cycle of threads forever stuck waiting for one another Contra Threads: Events Contra Threads: Events John Ousterhout: Why Threads Are a Bad Idea (for most purposes) casual All programmers wizards John Ousterhout: Why Threads Are a Bad Idea (for most purposes) casual All programmers wizards Visual basic programmers C programmers Visual basic programmers C programmers C++ programmers Thread programmers Event-driven Programming No concurrency: one execution stream Register interest in events (callbacks) Wait for events; invoke (short-lived) handlers Complicated only for unusual cases Easier to debug C++ programmers Thread programmers Event Loop H H H 3 H 4 H 5

2 Multi-object synchronization Transfer $00 from account A to account B A->subtract(00); B->add(00); Fine-grain locking Hash table: } Individual put(key, value) value = get(key) value = remove(key) one lock for whole table? one lock per bucket? Complexity vs Performance operations are atomic Sequence is not Beware of premature optimizations! Careful class design You design the API! Too Much Milk with objects Fridge! Note!! back to square one... Instead No panacea Fridge::checkForMilk(); Fridge::addMilk() Note::readNote(); notewritenote() Fridge::checkForMilkAndSetNoteIfNeeded() Fridge::addMilk() still need to think carefully how objects interact Serialization Divide work into logically separate tasks Ensure serializable execution of tasks tasks may execute concurrently......but result of each task equivalent to what would be obtained if tasks executed one at a time in some serial order A few ways to get there one big lock lock-all/release-all two phase locking Serialization Divide work into logically separate tasks Ensure serializable execution of tasks tasks may execute concurrently......but result of each task equivalent to what would be obtained if tasks executed one at a time in some serial order A few ways to get there one big lock lock-all/release-all need to know all locks two phase locking Lock(A,B) A=A+ B=B+ Unlock(A,B) Lock(C,D) C=C+3 D=D+4 Unlock(C,D) Lock(A,B) A=A+ B=B+ Unlock(A,B) Lock(A,B) A=A+5 B=B+6 Unlock(A,b) Equivalent sequential execution Lock(C,D) C=C+3 D=D+4 Unlock(C,D) Lock(A,B) A=A+5 B=B+6 Unlock(A,b)

3 Serialization Divide work into logically separate tasks Ensure serializable execution of tasks tasks may execute concurrently......but result of each task equivalent to what would be obtained if tasks executed one at a time in some serial order A few ways to get there one big lock lock-all/release-all two phase locking serializable Phase acquire locks upgrade reader to writer lock if necessary Phase release locks downgrade writer to reader lock if necessary ownership pattern Shared container put things in; take them out; access them without a lock (own them) Network Stage Parse Stage Render Stage One thread/network connection One thread/object One thread/object Solution: staged architecture Each stage has local state and some thread that operate on it No state shared across stages Read Static Page Deadlock A cycle of waiting among a set of threads, where each thread is waiting for some other thread in the cycle to take some action Mutually recursive locking Nested waiting Connect Read and Parse Send Page S waiting for unlock S waiting for unlock Generate Dynamic Page waiting for unlock S S waiting for signal

Dining Philosophers Necessary conditions for deadlock Deadlock only if the all hold Not sufficient in general Bounded resources P0 A finite number of threads can use a resource; resources are finite

Preventing deadlock holds one resource while waiting for another cycle Circular waiting Ti waits for Ti+ and holds a resource requested by Ti- sufficient if one instance of each resource P Avoiding

Habermann Remove one of the necessary conditions Provide sufficient resources Removes Bounded resources Preempt resources Removes No preemption Abort requests Removes Wait while holding Atomically

4 Dining Philosophers Necessary conditions for deadlock Deadlock only if the all hold Not sufficient in general Bounded resources P0 A finite number of threads can use a resource; resources are finite No preemption the resource is mine, MINE! (until I release it) waiting for owned by P4 P Wait while holding N philosophers; N plates; N chopsticks If all philosophers grab right chopstick deadlock! Preventing deadlock holds one resource while waiting for another cycle Circular waiting Ti waits for Ti+ and holds a resource requested by Ti- sufficient if one instance of each resource P Avoiding Deadlock: The Banker s Algorithm E.W. Dijkstra & N. Habermann Remove one of the necessary conditions Provide sufficient resources Removes Bounded resources Preempt resources Removes No preemption Abort requests Removes Wait while holding Atomically acquire all resources Removes Wait while holding Lock ordering Removes Circular waiting Nested waiting? Sum of maximum resources needs can exceed the total available resources if there exists a schedule of loan fulfillments such that all clients receive their maximal loan build their house pay back all the loan More efficient than acquiring atomically all resources

5 Living dangerously: Safe, Unsafe, Deadlocked The Banker s books Safe: For any possible set of resource requests, there exists one safe schedule of processing requests that succeeds in granting all pending and future requests Unsafe Deadlock ij = max amount of units of resource Rj needed by Pi m Claimi = ij = current allocation of Rj held by Pi m HasNowi = A request by Pk is safe if there is schedule P, P,...Pn such that, for all Pi, assuming the request is granted, i X Claimi-HasNowi + HasNowi Deadlocked: The system has at least one deadlock j= An Example An Example R R R3 R4 R R R3 R4 P 0 0 P P 0 0 R R R3 R4 5 0 R R R3 R4 R R R3 R4 P P P P P P P P5 0 0 P Is this a safe state? ij j = number of units of Rj available unlucky set of requests can force deadlock X j= Unsafe: There exists a set of (pending and future) resource requests that leads to a deadlock, for any schedule in which requests are processed A system s trajectory through its state space ij j= no deadlock as long as system can enforce safe schedule Safe X P Request R R R3 R4 R R R3 R4 5 0 P 0 P P P P P5 0 0 P Is this a safe state? P, P4, P,, P5 While safe sequence does not include all processes: Is there a Pi such that Requesti? if no, exit with unsafe if yes, add Pi to the sequence and set = + HasNowi Exit with safe

An Example An Example R R R 3 R 4 R R R 3 R 4 Request R R R 3 R 4 R R R 3 R 4 0 R R R 3 R 4 R R R 3 R 4 Request R R R 3 R 4 R R R 3 R 4 0 P 0 0 P 0 0 5 0 P P 0 0 P 0 0 0 0 P 7 5 0 0 7 5 0 7 5 0 0 4 0

6 An Example An Example R R R 3 R 4 R R R 3 R 4 Request R R R 3 R 4 R R R 3 R 4 0 R R R 3 R 4 R R R 3 R 4 Request R R R 3 R 4 R R R 3 R 4 0 P 0 0 P P P 0 0 P P P want to change its allocation to P want to change its allocation to Safe? Safe? Detecting Deadlock Detecting Deadlock 5 processes, 3 resources 5 processes, 3 resources R R R 3 Pending R R R 3 R R R 3 R R R 3 Pending R R R 3 R R R 3 P 0 0 P P 0 0 P Given the set of pending requests, is there a safe sequence? If no, deadlock Given the set of pending requests, is there a safe sequence? If no, deadlock Deadlock triggered when request is formulated, not granted

Advanced Synchronization and Deadlock

Advanced Synchronization and Deadlock A house of cards? Locks + CV/signal a great way to regulate access to a single shared object......but general multi-threaded programs touch multiple shared objects