1 / 6

E81 CSE 532S: Advanced Multi-Paradigm Software Development

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

nenet
Télécharger la présentation

E81 CSE 532S: Advanced Multi-Paradigm Software Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 cdgill@cse.wustl.edu

  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

  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() Lock

  6. 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 A Few Variations

More Related