1 / 5

E81 CSE 532S: Advanced Multi-Paradigm Software Development

E81 CSE 532S: Advanced Multi-Paradigm Software Development. The Active Object Pattern. Chris Gill Department of Computer Science and Engineering Washington University, St. Louis cdgill@cse.wustl.edu. Active Object Pattern. Active Object. Problem

stewart-velazquez
Download Presentation

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 The Active Object Pattern Chris Gill Department of Computer Science and Engineering Washington University, St. Louis cdgill@cse.wustl.edu

  2. Active Object Pattern Active Object • Problem • Concurrent access risks races or deadlock, blocking, etc. • Solution: “activate” the object • I.e., launch thread “inside” it • Decouples object method execution from invocation • Helps prevent deadlock • Helps increase concurrency • Implementation concerns • Ensuring thread safety • Increasing concurrency • Code and concurrency interact queue requesting thread worker thread

  3. Details: Retrieving Results Active Object Active Object • Completion of work is asynchronous • Blocking the request thread becomes a variant of the Monitor Object pattern • Can combine Active Object and ACT patterns • Encapsulate general completion rendezvous points as “Futures” • Can poll for result, or just block until it’s ready • Or, can post on requesting thread’s queue if it’s an active object as well request queue requesting thread worker thread result queue

  4. Details: Managing Queue Access Active Object • Need to synchronize access to queue methods • Particularly mutator methods • Want classic supplier-consumer behavior • Supplier sleeps when queue is full • Consumer sleeps when queue is empty • Need to manage carefully • Use condition variables • Increase concurrency opportunity • Maintain thread safety • Use high/low water marks • Avoid “silly window syndrome” queue requesting thread worker thread

  5. Design and Implementation Concerns • Key trade-off for lock-based data structures • Ensuring thread safety (no meaningful race conditions) • Increasing concurrency opportunities (deadlock == none) • Scope of serialization matters • How long is a lock held, and over how much data? • Minimize protected regions, use different locks if possible • I.e., “right mutex is locked … held for … minimum … time” • Data structure and concurrency semantics interact • Queue interface motivates use of condition variables • Note that notify_all() may be needed for exception safety! • Move expensive copying/allocation outside locked regions • Associating a lock per item also reduces lock granularity • Decoupling items is then essential (hash vs. tree vs. array example) • Using a readers/writer lock also may be helpful in some cases

More Related