1. Monitor Object Pattern
E81 CSE 532S: Advanced Multi-Paradigm Software Development
Concurrency Patterns
and the
Monitor Object Pattern
Chris Gill, Venkita Subramonian, Olcan Sercinoglu, Thomas Shepherd, Jim Luo
Department of Computer Science and Engineering
Washington University, St. Louis
Title slide

2. Concurrency Patterns Key issue: sharing resources across threads
Thread Specific Storage Pattern
Separates resource access to avoid contention among them
Monitor Object Pattern
One thread at a time can access the object’s resources
Active Object Pattern
One worker thread owns the object‘s resources
Half-Sync/Half-Async (HSHA) Pattern
A thread collects asynchronous requests and works on the requests synchronously (similar to Active Object)
Leader/Followers Pattern
Optimize HSHA for independent messages/threads

3. Design Forces
Need to prevent race conditions but allow incremental progress of threads within the object
Methods define (intuitive) synchronization boundaries
But, may need to check state etc. before proceeding
A refinement: only one method at a time is active within object
Synchronization must be transparent to caller
Client must not be concerned with synchronization
The executing method must be able to give up control
Other clients can access the object
Allows “controlled” concurrency
Object must be left “stable” during control transitions
Race conditions: uncontrolled concurrent changes
“Controlled” concurrency is one where internals are protected and deadlock is prevented
Stable: object-specific invariants must hold

4. Desired Internal Behavior
notify
Queue empty - wait
Queue

5. Solution: (Passive) Monitor Object
Make object a “Monitor Object”
Methods run in callers’ threads
Condition variables arbitrate use of a common shared lock
E.g., using a std::mutex, a std::unique_lock (must be able to unlock and re-lock it) and a std::condition_variable
Ensures incremental progress while avoiding race conditions
Thread waits on condition
Condition variable performs thread-safe lock/sleep and unlock/release operations
Thread released when it can proceed
E.g., when queue isn’t empty/full
Blocks caller until request can be handled, coordinates callers
Client Proxy List
(Monitor Object)
add()
Condition
lookup()
Transparent in the sense that the caller does not need to deal with external synchronization objects. Easy implementation is a big plus.
Lock

6. A Few Variations Can notify_one() or notify_all()
If it doesn’t matter which thread, just wake one up
If all need to see if it’s their turn, wake all of them
Can limit waiting time
Use wait_for() to return after a specified interval
Use wait_until() to return at a specified time
Can pass a predicate to wait (or wait_*) method(s)
Won’t return until predicate is satisfied (or call times out)
Helps to avoid spurious wake cases