1. Event Handling Patterns Asynchronous Completion Token
E81 CSE 532S: Advanced Multi-Paradigm Software Development
Event Handling Patterns
Asynchronous Completion Token
Chris Gill, Derek Chen-Becker, Frank Hunleth
Department of Computer Science and Engineering
Washington University, St. Louis
Title slide

2. Motivation for Event Handling Patterns
Context
Programs often have limited knowledge, learn about things via events
Limitations of synchronous architectures
Latency and jitter due to blocking, deadlock potential
But, a common trade-off is less complicated programs
Common Intent for Event Handling Patterns
Reconcile event handling, concurrency, distribution design forces in canonical ways, to reduce accidental complexity

3. Event Handling Patterns (continued)
Asynchronous Completion Token (Design Pattern)
Passes information between asynchronous activities
Reactor (Architectural Pattern)
Asynchronous notification of ready events
De-multiplexing and dispatch mechanisms for initiation
Acceptor-Connector (Design Pattern)
Decouples connection establishment from connection use
Decouples passive role from active role during connection establishment
Often used with the reactor
Proactor (Architectural Pattern)
Asynchronous notification of completion events
Small pattern languages involving event handling
Active object + ACT (asynch computations)
Reactor + Acceptor/Connector + ACT (distributed systems)
Limitations of synchronous architectures:
Threading overhead (context switch, OS thread overhead)
Less scalable than asynchronous
Asynchronous model matches better the flow of events in GUIs and network servers
What tradeoffs are made when moving from a synchronous to an asynchronous architecture?
Need to correlate asynchronous requests to replies
Need to demultiplex completions
Need to maintain state between requests and replies
How does ACT help mitigate these?
Provides mechanism to correlate requests to replies
Can provide efficient demultiplexing

4. Photo Courtesy of Derek Chen-Becker and Frank Hunleth
Asynchronous Completion Token (ACT)
Photo Courtesy of Derek Chen-Becker and Frank Hunleth
Also Known as the “Cookie” Pattern

5. When Should We Use ACT? Context Problem Event-driven systems
Invocation and response are asynchronous
E.g., functions dispatched using std::async, std::packaged_task, or in separate threads
Problem
Completion events must be de-multiplexed
Service does not know what a client needs to be able to de-multiplex responses
Communication overhead must be minimal
De-multiplexing should be efficient

6. ACT Solution Service (eventually) passes “cookie” to client
Examples with C++11 futures and promises
A future (eventually) holds ACT (or an exception) from which initiator can obtain the result
Client thread can block on a call to get the data or can repeatedly poll (with timeouts if you’d like) for it
A future can be packaged up with an asynchronously running service in several ways
Directly: e.g., returned by std::async
Bundled: e.g., via a std::packaged_task
As a communication channel: e.g., via std::promise
A promise can be kept or broken
If broken, an exception is thrown to client

7. Some ACT Representations
Data ACTs
The most straightforward variation, holds result directly
Pointer ACTs
E.g. use T* to pass event handler’s memory location
Issues: portability, inheritance/interface polymorphism
Iterator-style ACTs
Index into an array, STL iterator, etc.
Watch out for copy/move semantics, etc.
Memento/Command ACTs
Holds all necessary information for response handler upcall
Pointer ACT: void* may take up different numbers of bytes depending on the platform.
How to choose?
Pointer – local; no concerns about getting bad pointers back; don’t care about type safety if void*
Object Reference ACTs – have middleware support; distributed calls; like type safety
Index ACTs – Easier to validate; needed if state structures are remapped with shutdown
Memento ACTs – Small amount of state; ACT used over long periods of time

8. Potential Liabilities
Memory (and ) leaks
Especially in client, if service doesn’t return ACT
Need to use RAII, reference counted smart pointers, etc., to ensure entries are cleaned up
Race conditions and deadlock
Global vs. local identity, expire/retry
Application remapping
Affects pointer ACTs, sequence numbers etc.
E.g., application crashes and restarts may remap pointer addresses
Security implications
Authentication, authorization, privacy
Security implications:
Authentication
If service can’t be trusted, need to verify contents.
Easier with index ACTs
Make sure that responses aren’t spoofed
Authorization
Authorization may change between ACT creation and response. E.g. web page authorization cookie
Privacy
ACT contents may represent private information
Legal, corporate, or user policy may limit contents and exposure