Deadlock Prevention and Avoidance Synchronization is Difficult 7L. - PDF document

4/29/2018 Deadlock Prevention and Avoidance Synchronization is Difficult 7L. Higher level synchronization • recognizing potential critical sections 7M. Lock-Free operations – potential combinations of events – interactions with other pieces of code 8A. Deadlock Overview • choosing the mutual exclusion method 8B. Deadlock Avoidance – there are many different mechanisms 8C. Deadlock Prevention – with different costs, benefits, weaknesses 8D. Monitoring and Recovery • correctly implementing the strategy 8E. Priority Inversion – correct code, in all of the required places – maintainers may not understand the rules Deadlock, Prevention and Avoidance 1 Deadlock, Prevention and Avoidance 2 We need a “Magic Bullet” Monitors – Protected Classes • We identify shared resources • each monitor class has a semaphore – objects whose methods may require serialization – automatically acquired on method invocation • We write code to operate on those objects – automatically released on method return – automatically released/acquired around CV waits – just write the code • good encapsulation – assume all critical sections will be serialized • Complier generates the serialization – developers need not identify critical sections – clients need not be concerned with locking – automatically generated locks and releases – protection is completely automatic – using appropriate mechanisms • high confidence of adequate protection – correct code in all required places Deadlock, Prevention and Avoidance 3 Deadlock, Prevention and Avoidance 4 Monitors: use Evaluating: Monitors • correctness monitor CheckBook { – complete mutual exclusion is assured // class is locked when any method is invoked private int balance; • fairness public int balance() { – semaphore queue prevents starvation return(balance); • progress } public int debit(int amount) { – inter-class dependencies can cause deadlocks balance -= amount; • performance return( balance) – coarse grained locking is not scalable } } Deadlock, Prevention and Avoidance 5 Deadlock, Prevention and Avoidance 6 1

4/29/2018 Java Synchronized: use Java Synchronized Methods • each object has an associated mutex class CheckBook { – acquired before calling a synchronized method private int balance; public int balance() { – nested calls (by same thread) do not reacquire return(balance); – automatically released upon final return } • static synchronized methods lock class mutex // object is locked when this method is invoked public synchronized int debit(int amount) { • advantages balance -= amount; – finer lock granularity, reduced deadlock risk return( balance) • costs } } – developer must identify serialized methods Deadlock, Prevention and Avoidance 7 Deadlock, Prevention and Avoidance 8 Evaluating Java Synchronized Methods Encapsulated Locking • correctness • opaquely encapsulate implementation details – correct if developer chose the right methods – make class easier to use for clients • fairness – preserve the freedom to change it later • locking is entirely internal to class – priority thread scheduling (potential starvation) – search/update races within the methods • progress – critical sections involve only class resources – safe from single thread deadlocks – critical sections do not span multiple operations • performance – no possible interactions with external resources – fine grained (per object) locking – selecting which methods to synchronize Deadlock, Prevention and Avoidance 9 Deadlock, Prevention and Avoidance 10 Client Locking Non-Blocking Single Reader/Writer int SPSC_put(SPSC *fifo, unsigned char c) { int SPSC_get(SPSC *fifo) { • Class cannot correctly synchronize all uses if (SPSC_bytesIn(fifo) == 0) if (SPSC_bytesIn(fifo) == fifo->full) • critical section spans multiple class operations return(-1); return(-1); int ret = *(fifo->read); *(fifo->write) = c; – updates in a higher level transaction if (fifo->read == fifo->wrap) if (fifo->write == fifo->wrap) fifo->read = fifo->start; • client-dependent synchronization needs fifo->write = fifo->start; else else – locking needs depend on how object is used fifo->read++; fifo->write++; return(ret); – client may control access to protected objects return( c ); } – client may select best serialization method } int SPSC_bytesIn(SPSC *fifo) { return(fifo->write >= fifo->read ? • potential interactions with other resources fifo->write – fifo->read : fifo->full – (fifo->read – fifo->write)); – deadlock prevention must be at higher level } Deadlock, Prevention and Avoidance 11 Mutual Exclusion and Asynchronous Completion 12 2

4/29/2018 Solving the checkbook problem Atomic Instructions – Compare & Swap /* int current_balance; * Concept: Atomic Compare and Swap Writecheck( int amount ) { * this is implemented in hardware, not code int oldbal, newbal; */ do { oldbal = current_balance; int CompareAndSwap( int *ptr, int expected, int new) { newbal = oldbal - amount; int actual = *ptr; if (newbal <0) return (ERROR); if (actual == expected) } while (!compare_and_swap( &current_balance, oldbal, newbal)) *ptr = new; C 1 ... return( actual ); } } Mutual Exclusion and Asynchronous Completion 13 IPC, Threads, Races, Critical Sections 14 Lock-Free Multi-Writer Spin Locks vs Atomic Updates void SLL_push(SLL *head, SLL *element) { do { // push an element on to a singly linked LIFO list SLL *prev = head->next; void SLL_push(SLL *head, SLL *element) { element->next = prev; do { } while ( CompareAndSwap(&head->next, prev, element) != prev); } SLL *prev = head->next; element->next = prev; DLL_insert(DLL *head, DLL*element) { while(TestAndSet(lock,1) == 1); } while ( CompareAndSwap(&head->next, prev, element) != prev); DLL *last = head->prev; } element->prev = last; element->next = head; last->next = element; head->prev = element; lock = 0; } Mutual Exclusion and Asynchronous Completion 15 Mutual Exclusion and Asynchronous Completion 16 (Spin Locks vs Atomic Update Loops) Evaluating Lock-Free Operations • both involve spinning on an atomic update • Effectiveness/Correctness – but they are not the same – effective against all conflicting updates • a spin-lock – cannot be used for complex critical sections • Progress – spins until the lock is released – which could take a very long time – no possibility of deadlock or convoy • an atomic update loop • Fairness – spins until there is no conflict during the update – small possibility of brief spins – impossible to be preempted holding lock • Performance – conflicting updates are actually very rare – expensive instructions, but cheaper than syscalls Mutual Exclusion and Asynchronous Completion 17 Mutual Exclusion and Asynchronous Completion 18 3

4/29/2018 What is a Deadlock? Resource Dependency Graph • Two (or more) processes or threads Thread 1 Thread 2 – cannot complete without all required resources Deadlock! – each holds a resource the other needs Thread 2 Thread 1 • No progress is possible acquires a acquires a lock for lock for – each is blocked, waiting for another to complete Critical Critical Section B Section A • Related problem: livelock Thread 2 Thread 1 – processes not blocked, but cannot complete requests a requests a lock for lock for • Related problem: priority inversion Critical Critical Section A – high priority actor blocked by low priority actor Section B Deadlock, Prevention and Avoidance 19 The Dining Philosophers Problem Why Study Deadlocks? • A major peril in cooperating parallel processes Five philosophers they eat whenever five plates of pasta they choose to – they are relatively common in complex applications five forks – they result in catastrophic system failures • Finding them through debugging is very difficult one requires two forks to eat pasta, – they happen intermittently and are hard to diagnose but must take them – they are much easier to prevent at design time one at a time • Once you understand them, you can avoid them – most deadlocks result from careless/ignorant design they will not the problem negotiate with demands an – an ounce of prevention is worth a pound of cure one-another absolute solution Deadlock, Prevention and Avoidance 21 Deadlock, Prevention and Avoidance 22 (The Dining Philosophers Problem) Deadlocks May Not Be Obvious • process resource needs are ever-changing • the classical illustration of deadlocking – depending on what data they are operating on • it was created to illustrate deadlock problems – depending on where in computation they are • it is a very artificial problem – depending on what errors have happened – it was carefully designed to cause deadlocks • modern software depends on many services – changing the rules eliminate deadlocks – most of which are ignorant of one-another – but then it couldn't be used to illustrate deadlocks – each of which requires numerous resources • services encapsulate much complexity – we do not know what resources they require – we do not know when/how they are serialized Deadlock, Prevention and Avoidance 23 Deadlock, Prevention and Avoidance 24 4