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

kurser.iha.dk

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

More magazines by this user
Similar magazines