SPL/2010 Guarded Methods and Waiting 1

SPL/2010 Reminder! ● Concurrency problem: asynchronous modifications to object states lead to failure of thread computation (pre-condition is not met) 2

SPL/2010 Overview ● Techniques to deal with potential failures ● check all invariants and preconditions before performing action ● refuse to perform actions unless they can ensure that these actions will succeed ● exceptions, exception handling code 3

SPL/2010 4

Policies for failed preconditions/invariants ● Balking. throw exception if precondition fails. try, and if you cannot succeed, fail fast ● Guarded suspension. suspend method invocation (and thread) until precondition becomes true. ● Time-outs. between balking and suspension. Bounded wait for precondition to become true. 5

SPL/2010 Today ● guarded suspension ● general suspension mechanisms in Java RTE 6

SPL/2010 Guarded suspension and time-outs in concurrent software ● abstract queue supports add() get() size() 7

SPL/2010 Guards = special conditionals ● Conditionals in sequential programs: ● if statement check condition on method entry ● if false - no wait - can never become true 8

SPL/2010 Queue impl. Balking 9

SPL/2010 Guarded suspension ● asynchronous state changes can happen ● precondition may hold in the future ● wait until precondition holds ● guard asserts that another thread will make required state changes… ● Time-outs - soft guards - balking policy if wait for too long 10

SPL/

SPL/2010 Java Mechanics for Guarded Suspension ● Wait/Notify constructs - simple, mechanism for suspension in multi-threaded context 1. mechanism semantics 2. higher level constructs to simplify usability 12

SPL/2010 wait() ● threads may wait() until some other thread wakes them up ● each object has a wait set - similar to locks ● entities possessing locks and wait sets are called monitors ● maintained internally by the JVM ● set holds threads blocked by wait on object ● until notifications are invoked or waits released ● threads enter the queue of an object, o, by invoking the wait() method of o. A thread wishing to wakeup threads from the queue of o may call o.notify() (or o.notifyAll()) to wakeup just one thread (resp. all of the threads) waiting in the wait set of o. 13

SPL/2010 notify() ● threads enter wait queue of object o by invoking the wait() of o. ● thread wakeups threads from queue of o by: o.notify()/o.notifyAll() 14

SPL/2010 wait/notify cycle ● o.wait() - wait invocation ● current thread calling wait() is blocked. ● JVM places thread in wait set of o. ● o.notify() - notify invocation ● arbitrarily thread T is removed from o’s wait set ● T is resumed from the point of wait(). ● o.notifyAll() ● like notify except for all threads in o’s wait set 15

SPL/2010 Interrupting Threads ● Special JVM exception to threads: ● thread may need to stop waiting for a notify() (example when program needs to exit) ● InterruptedException – wait() method exits immediately 16

SPL/2010 Handle InterruptedException 17 ?

SPL/2010 Back to queue ● Producer-Consumer design pattern ● Producer produces objects /Consumer needs process ● decouple processes that produce and consume data at different rates ● queue data in producer loop / process in consumer loop at own pace 18

SPL/

SPL/2010 ● video player example: ● Producer read the file from disk and give chunks of data to Consumer – add() ● Consumer decodes and play – take() ● Guard add() / take() methods, such that all preconditions are respected – wait() until the preconditions hold. 20

SPL/2010 Producer-Consumer Queue 21

SPL/

SPL/2010 ● thread trying to get() when queue is empty will wait in wait set of queue ● thread which successfully add()s an object to queue will wake him up (and vice versa) ● What is wrong? ● No synchronization 23

SPL/2010 What is wrong? Guard atomicity ● two Consumer threads and one producer The ● queue is empty at first ● consumers execute take() - block (size=0) ● producer calls add() once, notifyAll() ● both consumers wake up. both execute vec_.remove(0) ● precondition does not hold for one of them 24

SPL/2010 What is wrong? Wait atomicity ● one producer and one consumer ● first runs the consumer, calls take() ● consumer checks condition, and is stopped right after (scheduler) ● producer calls add() successfully – calls notifyAll() - no thread in wait set at that time ● consumer is resumed and calls this.wait() ● queue not empty-consumer miss notification. 25

SPL/2010 Guard Atomicity - while loop 26

SPL/2010 Solution? ● while loop ensures after waking up, checks precondition one more time ● no synchronization ● use notify() instead of notifyAll() ? dangerous... 27

SPL/2010 Wait Atomicity ● ensure no one calls notify() between precondition check and wait. ● make both check and wait atomic with relation to notify mechanism. ● use single lock to protect them (?) 28

SPL/2010 Wait Atomicity ● thread get hold of a lock ● check ● wait() - enter a wait set ● no other thread may get lock and wake us up! 29

SPL/2010 Wait Atomicity ● Java solution: ● call to wait() or notifyAll() - calling thread must hold object's monitor (lock). ● enter wait() - thread (involuntarily) releases lock ● before exit wait() - thread must relock object (why?) 30

SPL/

SPL/2010 Wait/Notify Mechanism ● thread T calls o.wait() ● JVM checks that T holds o's lock (if not, exception IllegalMonitorState). ● T is blocked, and lock of o is released. ● JVM places T in the wait set associated with o. 32

SPL/2010 Wait/Notify Mechanism ● thread T calls o.notify() ● JVM checks that T holds o's lock. if not exception is thrown. ● arbitrarily thread T' is removed from wait set ● T' tries to re-acquire the lock of o (T' blocks until it does). ● T' is resumed from the point of its wait(). 33

SPL/2010 Wait/Notify Mechanism ● o.notifyAll() - steps occur simultaneously for all threads in wait set of o. ● Thundering Herd phenomena – all threads try to acquire the lock competing with each other. ● holding the monitor's lock check is done at runtime and not at compile time. 34

SPL/

SPL/

SPL/2010 Rules of Thumb for Wait and Notify ● Guarded wait - for each condition that needs to be waited on, write a guarded wait loop that causes the current thread to block if the guard condition is false. 37

SPL/2010 Rules of Thumb for Wait and Notify ● Guard atomicity - Condition checks must always be placed in while loops. ● When action is resumed, waiting thread doesn't know if condition is true ● to maintain safety, it must check again. ● thread can wake up without notify, interrupt, or timing out - spurious wakeup. 38

SPL/2010 Rules of Thumb for Wait and Notify ● Multiple guard atomicity If there are several conditions which need to be waited for, place them all in the same loop. 39

SPL/2010 Rules of Thumb for Wait and Notify ● Don't forget to wake up - ensure liveness, classes must wake up waiting threads. ● when value of field in guard changes - waiting threads must be awakened to recheck conditions 40

SPL/2010 Rules of Thumb for Wait and Notify ● notifyAll() - multiple threads wait on same wait set: ● at least two threads waiting for different conditions, ● ensure that no thread misses an event. 41

SPL/2010 notify() Vs. notifyAll(): ● queue which has add() / addTwo() methods ● Thread t1 waits for queue in add() checking room for one object, ● thread t2 waits in addTwo() checking room for two objects. ● get() method calls notify() and thread t2 wakes up ● room for one object in queue, t2 goes back to sleep. ● t1 will not be woken up at all, even though there is space in the queue. 42

SPL/2010 Sophisticated Primitives ● Wait and Notify: ● basis for higher level constructs. ● general constructs ● Specific mechanisms make code easier to understand and demand less details when using them: ● Semaphores ● Readers-Writers locks. 43

SPL/2010 Semaphores ● Object controls bounded number of permits (permit = train ticket): ● Threads ask semaphore for permit (a ticket). ● If semaphore has permits available, one permit is assigned to requesting thread. ● If no permit available, requesting thread is blocked until permit is available – when a thread returns permit received earlier 44

SPL/2010 implementation 45

SPL/2010 Java Semaphore class properties ● not re-entrant – thread calls acquire() twice, must release() twice! ● semaphore can be released by a thread other than owner (unlike lock) – no ownership. ● constructor accepts fairness parameter – if t1 requested before t2 it will receive first ● services as tryAcquire and managing permits. 46

SPL/2010 SimpleQueue vs. Semaphore ● SQ: add(),remove() call notifyAll() call. ● Sem: release() calls notifyAll() method acquire() does not. ● SQ:add(), remove() call wait() ● Sem: method acquire() calls wait() method release() does not. 47

SPL/2010 SimpleQueue vs. Semaphore ● SQ: add(),remove() - non-empty preconditions correspond to 2 distinct states of the Queue: empty or full. ● Sem: acquire() has pre-condition and release() has no pre-condition. ● release() does not need to call wait(). ● acquire() call wait() - symmetric call in release() for notifyAll() (for each wait() - corresponding notifyAll() that unblocks). 48

SPL/2010 Readers/Writers Example ● allow readers and writers to access a shared resource under different policies ● Policy: ● several readers can access resource together ● only one writer can access resource at given time ● Example: – Readers wait if writer is pending – One writer at a time can access the shared resource, if no readers are reading from it 49

SPL/

SPL/