Monitors and Blocking Synchronization By Tal Walter

Outline Monitors Conditions Readers-Writers Locks Reentrant locks / semaphores implementations

Motivation for Monitors Programming with locks often gets complicated and cumbersome In order to program something that uses multiple cores, you have to use and understand locks. Monitors encapsulate a class with it’s synchronization needs Provides another layer of abstraction User doesn’t have to be aware of locks at all.

What’s a Monitor? Monitors are a structured way of combining synchronization and data. A class encapsulates both data and methods in the same way that a monitor combines data, methods, and synchronization in a single modular package.

An Example mutex.lock(); try { queue.enq(x) } finally { mutex.unlock(); } Suppose an application has two threads, a producer and a consumer, that communicate through a shared FIFO queue. We could have the threads share two objects: an unsynchronized queue, and a lock to protect the queue. The producer would be:

An Example Suppose the queue is bounded. What to do on queue.enq(x)? Would it pass? What if the queue is full? Would it block? Depends on internal state mutex.lock(); try { queue.enq(x) } finally { mutex.unlock(); }

An Example The user of the queue will have to figure out a cumbersome synchronization protocol. The queue should manage its own synchronization. A queue that also has the synchronization logic encapsulated is a synchronized queue, a Monitor.

Spinning/Blocking-a reminder If a thread cannot immediately acquire a lock, it can either spin, repeatedly testing whether the desired event has happened, or it can block, giving up the processor for a while to allow another thread to run.

Conditions – Why? Back to the queue, a thread that waits to deq(x) on an empty queue needs to be blocked After the waiting thread went to sleep, it needs a way to be awakened, to reacquire the lock and try again. That’s where conditions come in:

Conditions – What? A condition is an object that’s associated with a lock, and is created by calling that lock’s newCondition() method. If the thread holding that lock calls the associated condition’s await() method, it releases that lock and suspends itself, giving another thread the opportunity to acquire the lock.

Conditions – What? When that condition is signal()ed by some other thread, the noble thread awakens (or not) and reacquires the lock, perhaps competing with other threads in the process.

12 A Monitor Lock Critical Section waiting room Lock() unLock()

13 Unsuccessful Deq Critical Section waiting room Lock() await() Deq() Oh no, Empty!

14 Another One Critical Section waiting room Lock() await() Deq() Oh no, Empty!

15 Enqueur to the Rescue Critical Section waiting room Lock() signalAll() Enq( ) unLock() Yawn!

16 Yawn! Monitor Signalling Critical Section waiting room Yawn! Awakend thread might still lose lock to outside contender…

17 Dequeurs Signalled Critical Section waiting room Found it Yawn!

18 Yawn! Dequeurs Signalled Critical Section waiting room Still empty!

19 Dollar Short + Day Late Critical Section waiting room

20 Lost Wake-Up Critical Section waiting room Lock() signal () Enq( ) unLock() Yawn!

21 Lost Wake-Up Critical Section waiting room Lock() Enq( ) unLock() Yawn!

22 Lost Wake-Up Critical Section waiting room Yawn!

23 Lost Wake-Up Critical Section waiting room Found it

24 What’s Wrong Here? Critical Section waiting room zzzz….!

A Queue Example An example of a queue with conditions who are Signal()ed everytime instead of using SignalAll() when transitioning:

A Queue Example

Readers-Writers Locks A lot of times we can split a data structure’s methods into “readers” that return information about the object’s state without modifying the object, and “writers” who actually modify the object. There can be many readers at once, or a writer, but only one. A readers–writers lock allows multiple readers or a single writer to enter the critical section concurrently. In practice, we’ll call readLock().lock() and writeLock().lock() accordingly, instead of calling lock.lock().

Readers-Writers Locks We’ll have a look at 2 Readers–Writers Lock implementations. First one is pretty straight-forward, The SimpleReadWriteLock

SimpleReadWriteLock

ReadLock

WriteLock OR

Introducing fairness into the scheme If readers are much more frequent than writers, as is usually the case, then writers could be locked out for a long time by a continual stream of readers. The FifoReadWriteLock class, that will be shown next, shows a way to give writers priority.

FifoReadWriteLock – The Idea FifoReadWriteLock ensures that once a writer calls the write lock’s lock() method, no more readers will be able to acquire the read lock until the writer has acquired and released the write lock. Eventually, the readers holding the read lock will drain out without letting any more readers in, and the writer will acquire the write lock.

FifoReadWriteLock

ReadLock

WriteLock

The Reentrant Lock It’s simply a lock that can be obtained multiple times by the same thread that originally acquired it. Let’s see how do we implement a reentrant lock using a non reentrant one and a condition:

The Reentrant Lock – implementation

Another use for conditions - Semaphores We all know what a semaphore is, let’s see the implementation (don’t worry it’s pretty short)

Semaphore implementation

Summary Monitors Conditions Readers-Writers Locks Reentrant locks / semaphores implementations

That’s it!