monitors and blocking synchronization by tal walter
Post on 19-Dec-2015
220 views
TRANSCRIPT
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!