Monitors & Blocking Synchronization 1

Producers & Consumers Problem Two threads that communicate through a shared FIFO queue. These two threads can’t do it simultaneously. 2

1. share two objects: - unsynchronized queue - lock to protect the queue. The producer looks like : Sounds right?? 1. Sharing Everything (1) ©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 3

1. Sharing Everything (2) what if the queue is bounded ? The decision whether to block the call or let it proceed depends on the queue’s internal state. Everybody must keep track of both the lock and the queue objects. The app correctness depends on every thread following the same locking conventions. 4

2. Data Structure Manages it’s own synchronization (1) The queue has it’s internal lock, acquired by each method when it is called and released when it returns. If a thread tries to enqueue an item to a full queue - the enq() can detect the problem, suspend the caller, and resume when the queue has room. 5

We want to synchronize the actions while keeping the correctness of the structure (!!) While a thread is waiting for another thread to place an item in an empty queue, it needs to release the lock. Afterwards it needs a way to be notified when to reacquire the lock(when there is a chance that the queue in not empty). 2. Data Structure Manages it’s own synchronization (2) 6

Condition Objects The ability to release a lock temporarily is provided by the Condition object, associated with a lock. Behind the scenes: - A thread acquires a lock. - If the condition hasn’t been met– the thread releases the lock and waits. - When the condition has been met – all the waiting threads are awakened. - When it is awakened – tries to win again the lock(maybe competing with other threads). 7

Example: ©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 8

[ Capacity ]; ©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 9

10

Optimization There is no need to signal() every time after enq() – only when the queue actually transitions from empty to non- empty. 11

©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 12

Weak spot – Lost Wakeups As locks vulnerable to deadlocks, Condition objects vulnerable to lost wakeups, in which one or more threads wait forever without realizing that the condition has become true. Solutions (either works here): 1. always signal all processes waiting on a condition, not just one. 2.Specify a time out when waiting 13

A combination of methods, mutual exclusion locks and condition objects is called a MONITOR 14

Readers & Writers 15

Readers Writers Problem Many shared objects have the property that most method calls return information about the object without modifying it (READERS), while only a small number of calls actually modify the object (WRITERS). There is no need for readers to synchronize with one another. Writers on the other hand, must lock out readers as well as other writers. 16

Implementation interface: No thread can acquire the write lock while any thread holds wither the write lock or the read lock No thread can acquire the read lock while any thread holds the write lock 17

©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 18

©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 19

> 0 || writer ) { ©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 20

Starvation!!! The code works – but there is: Starvation of the writers!!! If readers are much more frequent than writers, as is usually the case, then writers could be locked out for a long time by continual stream of readers. 21

Giving writers priority One way to give writers priority is to ensure that once a writer calls the writer’s lock method, then no more readers will be able to acquire the read lock until the writer has done with his writing. Eventually, the readers holding the read lock will drain out without letting any more readers in, and the writer will acquire the write lock. 22

} ©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 23

(writer) { while ( readers > 0 ) { condition.await(); } ©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 24

Reentrant Lock Thread that attempts to reacquire a lock it already holds will deadlock with itself. When do you think this situation can happen? As we said before, a thread that is holding the reentrant lock can acquire it again without blocking. There is an importance to thread’s identity. An example of implementation reentrant lock with a non-reentrant lock. 25

©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 26

©”The Art of Multiprocessor programming” by Maurice Herlihy & Nir Shavit 27

Before: After: Hope you enjoyed the lesson! 28