Monitors & Blocking Synchronization 1. Producers & Consumers Problem Two threads that communicate through a shared FIFO queue. These two threads can’t

1

Monitors & Blocking Synchronization

2

Producers & Consumers Problem

• Two threads that communicate through a shared FIFO queue.

• These two threads can’t do it simultaneously.

3

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

4

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.

5

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.

6

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

7

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

8

Example:


9

[Capacity;]


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

11

Optimization

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

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

13

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

14

A combination of methods, mutual

exclusion locks and condition objects is called

a MONITOR

15

Readers & Writers

16

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.

17

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



20

> 0 || writer ) {


21

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.

22

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.

23

}


24

(writer) {

while ( readers > 0 ) {condition.await();

}


25

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.



28

Before: After :

Hope you enjoyed the lesson!

Documents

Monitors & Blocking Synchronization 1. Producers & Consumers Problem Two threads that communicate through a shared FIFO queue. These two threads can’t