Monitors and Blocking Synchronization By Tal Walter.

Monitors and Blocking Monitors and Blocking SynchronizationSynchronization

By Tal Walter

OutlineOutline

Monitors Conditions Readers-Writers Locks Reentrant locks / semaphores

implementations

Motivation for MonitorsMotivation 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?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 ExampleAn 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 ExampleAn 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 ExampleAn 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 Spinning/Blocking-a reminderreminder

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?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?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?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

Cri

tical S

ecti

on

waiting roomLock(

)

unLock()

13

Unsuccessful Deq

Cri

tical S

ecti

on

waiting roomLock

()

await()

Deq()

Oh no, Empty!

14

Another One

Cri

tical S

ecti

on

waiting roomLock

()

await()

Deq()

Oh no, Empty!

15

Enqueur to the Rescue

Cri

tical S

ecti

on

waiting roomLock(

)

signalAll()

Enq( )

unLock()

Yawn!Yawn!

16

Yawn!

Monitor Signalling

Cri

tical S

ecti

on

waiting room

Yawn!

Awakend thread might still lose lock to outside contender…

17

Dequeurs Signalled

Cri

tical S

ecti

on

waiting room

Found it

Yawn!

18

Yawn!

Dequeurs Signalled

Cri

tical S

ecti

on

waiting room

Still empty!

19

Dollar Short + Day Late

Cri

tical S

ecti

on

waiting room

20

Lost Wake-Up

Cri

tical S

ecti

on

waiting roomLock(

)

signal ()Enq( )

unLock()

Yawn!

21

Lost Wake-Up

Cri

tical S

ecti

on

waiting roomLock(

)

Enq( )

unLock()

Yawn!

22

Lost Wake-Up

Cri

tical S

ecti

on

waiting room

Yawn!

23

Lost Wake-Up

Cri

tical S

ecti

on

waiting room

Found it

24

What’s Wrong Here?

Cri

tical S

ecti

on

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 LocksReaders-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 LocksReaders-Writers Locks

We’ll have a look at 2 Readers–Writers Lock implementations.

First one is pretty straight-forward,The SimpleReadWriteLock

SimpleReadWriteLockSimpleReadWriteLock

ReadLockReadLock

WriteLockWriteLock

OR

Introducing fairness into Introducing fairness into the schemethe 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 FifoReadWriteLock – The IdeaIdea 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.

FifoReadWriteLockFifoReadWriteLock

ReadLockReadLock

WriteLockWriteLock

The Reentrant LockThe 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 – The Reentrant Lock – implementationimplementation

Another use for conditions Another use for conditions - Semaphores- Semaphores

We all know what a semaphore is, let’s see the implementation (don’t worry it’s pretty short)

Semaphore Semaphore implementationimplementation

SummarySummary

Monitors Conditions Readers-Writers Locks Reentrant locks / semaphores

implementations

That’s it!That’s it!