However, a management application may have requested many
different agents to send it notifications asynchronously for many
types of events, each of which may be processed differently in the
management application. For each completion event, therefore, the
management application must determine the appropriate action(s),
such as updating an administrators display or logging the event to a
One way a management application could match up asynchronous
operation requests with their subsequent completion event responses
would be to spawn a separate thread for each event registration
operation it invoked on an agent. Each operation would block
synchronously, waiting for its agents responses. The action and state
information required to process agent responses could be stored
implicitly in the context of each thread's run-time stack.
Unfortunately, this synchronous multi-threaded design incurs
several drawbacks. For example, it may lead to poor performance due
to context switching, synchronization, and data movement
overhead.2 As a result, developing management applications using
separate threads to wait for each operation completion response can
yield inefficient and overly complex solutions. Yet, the management
application must associate service responses with client operation
requests efficiently and scalably to ensure adequate quality of service
for all its agents.
Context An event-driven system where clients invoke operations asynchronously
on services and subsequently process the responses.
Problem When a client invokes an operation request asynchronously on one or
more services, each service indicates its completion by sending a
response back to the client. For each such completion response, the
client must perform the appropriate action(s) to process the results of
2. The Example section of the Reactor pattern (97) describes the drawbacks of
synchronous multi-threading in more detail.
Asynch View More »