Asynchronous Completion Token - Ingeniørhøjskolen i Århus

Distributed Real-Time
Systems
(TI-DRTS)
POSA2: Asynchronous Completion
Token Design Pattern
Version: 21-09-2009

Abstract
The Asynchronous Completion Token (ACT)
design pattern allows an application to
demultiplex and process efficiently the responses
of asynchronous operations it invokes on services
© Ingeniørhøjskolen i Århus
Slide 2

Context
• An event-driven system in which
applications invoke operations
asynchronously on services and
subsequently process the associated
service completion event responses
© Ingeniørhøjskolen i Århus
Slide 3

Problem
• A client application invokes one or more
services asynchronously
• Each service returns its response via a
completion event
• The client application must demultiplex
this event to the appropriate handler (as
fast as possible)
© Ingeniørhøjskolen i Århus
Slide 4

Solution
• Together with each asynchronous operation
invocation:
– transmit information that identifies how the initiator
should process the service’s response
• create an Asynchronous Completion Token (ACT)
• the ACT is passed to the service, which hold it – but does
not modify it
• Return this information to the initiator when the
operation finishes
• The initiator uses the ACT to identify the
completion handler
© Ingeniørhøjskolen i Århus
Slide 5

ACT Structure
«demultiplexes»
1..*
Completion
Handler
+handle_event()
Initiator
completion_action()
«uses»
calls
operations
1 1
1..*
Asynchronous
Completion
Token
Service
async_operation()
1
1..*
© Ingeniørhøjskolen i Århus
Slide 6

Sequence Diagram
:Initiator
:Completion
Handler
:Service
«create»
:ACT
ACT
async_operation()
notify()
ACT result
completion_action()
result
handle_event()
© Ingeniørhøjskolen i Århus
Slide 7

Implementation Steps
1. Define the ACT representation
2. Select a strategy for holding the ACT at the
initiator
3. Determine how to pass the ACT from the
initiator to the service
4. Determine a strategy for holding the ACT in
the service
5. Determine the number of times an ACT can
be used
6. Determine the initiator strategy for
demultiplexing ACTs to completion handler
hook methods
© Ingeniørhøjskolen i Århus
Slide 8

1. Define the ACT Representation
• Pointer ACTs
– pointer to completion handler object (ok for
homogeneous platforms)
• Object reference ACTs
– e.g. CORBA’s object references provides a standard,
portable and inter-operable solution (initiator use
CORBA_narrow() operation to downcast)
• Index ACTs
– represented as an index into a table of completion
handlers
• for persistent completion handlers: use database identifiers or
offsets into memory-mapped files
© Ingeniørhøjskolen i Århus
Slide 9

2. Select a Strategy for holding the ACT
at the Initiator
• Implicit ACTs
– Defining it to be the address of the initiator
completion handler object
– Benefits: efficient time and space utilization
• Explicit ACTs
– The initiator hold its ACTs in an explicit data
structure
• for example a table of completion handlers
– Benefits: increased robustness and authenticity
• Initiators are responsible for freeing any
resources associated with ACTs
© Ingeniørhøjskolen i Århus
Slide 10

6. Determine the initiator demultiplexing
strategy
1. Queued completion events
– ACTs is placed in a completion event queue by a
service or by a local service proxy
– An initiator removes the ACT from a completion
event queue
– As shown in the Proactor pattern description (see
next slide)
2. Callbacks
– An initiator passes a callback function/object to the
service
– The ACTs can be returned as a parameter to the
callback object (can often be a Singleton)
© Ingeniørhøjskolen i Århus
Slide 11

6.1 Win32_Proactor_Implementation
void Win32_Proactor_Implementation::handle_events(
Time_value *wait_time) {
u_long num_bytes;
OVERLAPPED *act;
Bool status= GetQueuedCompletionStatus(completion_port_,
&num_bytes, 0, &act, wait_time ==0 ? 0 : wait_time->msec());
}
Async_Result *async_result= static_cast (act);
async_result->status(status);
if (status)
async_result->bytes_transferred(num_bytes);
else
async_result->error(GetLastError());
async_result->complete();
delete async_result;
(from proactor presentation)
© Ingeniørhøjskolen i Århus
Slide 12

6.1 Async_Stream_Read_Result (ACT)
class Async_Stream_Read_Result: public Async_Result {
public:
Async_Stream_Read_Result(Completion_Handler *ch) :
completion_handler_(ch) { }
// Adapter that dispatches the hook method
// on the cached completion handler
virtual void complete() {
completion_handler_->handle_event(
completion_handler_->get_handle(), READ_EVENT, *this);
}
private:
Completion_Handler *completion_handler_;
};
(from proactor presentation)
© Ingeniørhøjskolen i Århus
Slide 13

6.2 Generic Callback_Handler class
class Completion_Handler_ACT {
public:
virtual void handle_event(const Completion_Event &event)=0;
};
class Callback_Handler {
public: // Callback method
virtual void notify(const Completion_Event &event,
Completion_Handler_ACT *act) {
completion_event(event, act);
}
protected:
virtual void completion_event(const Completion_Event &event,
Completion_Handler_ACT *act) {
act->handle_event(event);
}
};
© Ingeniørhøjskolen i Århus
Slide 14

Management Example (1)
2
Window
2
Logger
Management
Application
1 subscribes at
Completion_
Handler_ACT
1
Management_
Agent_Proxy
+subscribe()
stores
Callback_
Handler
+notify()
© Ingeniørhøjskolen i Århus
1
1
Slide 15
Management_
Completion_
Handler
2
*

Management Example(2)
main
:Callback
Handler
event_
loop
topology_
window
callback_
handler
topology_
window
:Window
EVENT
database_
logger
database_
logger:
Logger
connection_act
connection_act
:Management_
Completion_
Handler
notify() connection_act event
subscribe()
agent_proxy:
Management_
Agent_Proxy
completion_
event()
event
handle_event()
update()
event
update()
event
© Ingeniørhøjskolen i Århus
Slide 16

Management Example (3)
class Management_Agent_Proxy {
public:
enum Event_Type { NEW_CONNECTIONS, FILE_TRANSFERS };
};
void subscribe( Callback_Handler *handler, Event_Type type;
Completion_Handler_ACT *act);
// ….
// ….
© Ingeniørhøjskolen i Århus
Slide 17

Management Example (4)
class Management_Completion_Handler :
public Completion_Handler_ACT {
public:
Management_Completion_Handler(Window *w, Logger *l) :
window_(w), logger_(l) { }
virtual void handle_event(const Completion_Event &event) {
window_->update(event);
logger_->update(event);
}
private:
Window *window_;
Logger *logger_;
};
© Ingeniørhøjskolen i Århus
Slide 18

Management Example (5)
int main() {
Callback_Handler callback_handler; // shared !
Management_Agent_Proxy agent_proxy = // …
Logger database_logger(DATABASE);
Logger console_logger(CONSOLE);
Window main_window(200,200);
Window topology_window(100,20);
Management_Completion_Handler connection_act(
&topology_window,&database_logger);
Management_Completion_Handler file_transfer_act(
&main_window,&console_logger);
agent_proxy.subscribe(&callback_handler,
Management_Agent_Proxy::NEW_CONNECTIONS, &connection_act);
agent_proxy.subscribe(&callback_handler,
Management_Agent_Proxy::FILE_TRANSFERS, &file_transfer_act);
run_event_loop();
}
© Ingeniørhøjskolen i Århus
Slide 19

ACT Benefits
• Simplified initiator data structures
• Efficient state acquisition (time efficient)
• Space efficiency
• Flexibility
• Non-dictatorial concurrency policies
© Ingeniørhøjskolen i Århus
Slide 20

ACT Liabilities
• Memory leaks
– if initiators use ACTs as pointers to
dynamically memory and services fails to
return the ACTs
• Authentication
– the initiator may need to authenticate the
ACT before using it
• Application re-mapping
© Ingeniørhøjskolen i Århus
Slide 21

Known Uses
• HTTP-Cookies
• Windows NT uses ACT in conjunction
with handles (see Proactor)
• POSIX Asynchronous I/O API
• CORBA demultiplexing (TAO Corba)
• Electronic medical image system
management
• Jini handback object – a Java based
example of ACT
© Ingeniørhøjskolen i Århus
Slide 22

Relation to other POSA2 Patterns
© Ingeniørhøjskolen i Århus
Slide 23