Active Object

An Object Behavioral Pattern forConcurrent Programming

R. Greg Lavender Douglas C. SchmidtG.Lavender@isode.com schmidt@cs.wustl.eduISODE Consortium Inc. Department of Computer Science

Austin, TX Washington University, St. Louis

An earlier version of this paper appeared in a chapter inthe book “Pattern Languages of Program Design 2” ISBN0-201-89527-7, edited by John Vlissides, Jim Coplien, andNorm Kerth published by Addison-Wesley, 1996.

Abstract

This paper describes the Active Object pattern, which decou-ples method execution from method invocation in order tosimplify synchronized access to an object that resides in itsown thread of control. The Active Object pattern allows oneor more independent threads of execution to interleave theiraccess to data modeled as a single object. A broad class ofproducer/consumer and reader/writer applications are well-suited to this model of concurrency. This pattern is com-monly used in distributed systems requiring multi-threadedservers. In addition, client applications, such as window-ing systems and network browsers, employ active objects tosimplify concurrent, asynchronous network operations.

1 Intent

The Active Object design pattern decouples method execu-tion from method invocation to enhance concurrency andsimplify synchronized access to an object that resides in itsown thread of control.

2 Also Known As

Concurrent Object and Actor

3 Example

To illustrate the Active Object pattern, consider the designof a communication Gateway [1]. A Gateway decouples co-operating components and allows them to interact withouthaving direct dependencies among each other [2]. The Gate-way shown in Figure 1 routes messages from one or moresupplier processes to one or more consumer processes in adistributed system [3].

WIDE AREA

NETWORK

SATELLITESSATELLITESTRACKINGTRACKINGSTATIONSTATION

PEERSPEERS

STATUS INFO

COMMANDS BULK DATA

TRANSFER

LOCAL AREA NETWORK

GROUNDSTATION

PEERS

GATEWAY

Figure 1: Communication Gateway

In our example, the Gateway, suppliers, and consumerscommunicate over TCP, which is a connection-oriented pro-tocol [4]. Therefore, the Gateway software may encounterflow control from the TCP transport layer when it tries tosend data to a remote consumer. TCP uses flow control toensure that fast suppliers or Gateways do not produce datamore rapidly than slow consumers or congested networkscan buffer and process the data.

To improve end-to-end quality of service (QoS) for allsuppliers and consumers, the entire Gateway process mustnot block waiting for flow control to abate over any one con-nection to a consumer. In addition, the Gateway must beable to scale up efficiently as the number of suppliers andconsumers increase.

An effective way to prevent blocking and to improve per-formance is to introduce concurrency into the Gateway de-sign. Concurrent applications allow the thread of control ofan objectO that executes a method to be decoupled from thethreads of control that invoke methods onO. Moreover, us-ing concurrency in the gateway enables threads whose TCP

1

connections are flow controlled to block without impedingthe progress of threads whose TCP connections are not flowcontrolled.

4 Context

Clients that access objects running in separate threads of con-trol.

5 Problem

Many applications benefit from using concurrent objects toimprove their QoS,e.g., by allowing an application to handlemultiple client requests in parallel. Instead of using single-threadedpassive objects, which execute their methods in thethread of control of the client that invoked the methods, con-current objects reside in their own thread of control. How-ever, if objects run concurrently we must synchronize accessto their methods and data if these objects are shared by mul-tiple client threads. In the presence of this problem, threeforces arise:

1. Methods invoked on an object concurrently should notblock the entire process in order to prevent degrading theQoS of other methods: For instance, if one outgoing TCPconnection to a consumer in our Gateway example becomesblocked due to flow control, the Gateway process should stillbe able to queue up new messages while waiting for flowcontrol to abate. Likewise, if other outgoing TCP connec-tions arenot flow controlled, they should be able to sendmessages to their consumers independently of any blockedconnections.

2. Synchronized access to shared objects should be sim-ple: Applications like the Gateway example are often hardto program if developers must explicitly use low-level syn-chronization mechanisms, such as acquiring and releasingmutual exclusion (mutex) locks. In general, methods that aresubject to synchronization constraints should be serializedtransparently when an object is accessed by multiple clientthreads.

3. Applications should be designed to transpar-ently leverage the parallelism available on a hard-ware/software platform: In our Gateway example, mes-sages destined for different consumers should be sent in par-allel by a Gateway over different TCP connections. If theentire Gateway is programmed to only run in a single threadof control, however, performance bottlenecks cannot be al-leviated transparently by running the Gateway on a multi-processor.

6 Solution

For each object that requires concurrent execution, decou-ple method invocation on the object from method execution.

This decoupling is designed so the client thread appears toinvoke an ordinary method. This method is automaticallyconverted into a method request object and passed to anotherthread of control, where it is converted back into a methodand executed on the object implementation.

An active object consists of the following components.A Proxy [5, 2] represents the interface of the object and aServant[6] provides the object’s implementation. Both theProxy and the Servant run in separate threads so that methodinvocation and method execution can run concurrently: theproxy runs in the client thread, while the servant runs in a dif-ferent thread. At run-time, the Proxy transforms the client’smethod invocation into aMethod Request, which is storedin anActivation Queueby aScheduler. The Scheduler runscontinuously in the same thread as the servant, dequeueingMethod Requests from the Activation Queue when they be-come runnable and dispatching them on the Servant that im-plements the Active Object. Clients can obtain the results ofa method’s execution via theFuturereturned by the Proxy.

7 Structure

The structure of the Active Object pattern is illustrated in thefollowing Booch class diagram:

Proxy

Future m1()Future m2()Future m3()

Scheduler

dispatch()enqueue()

INVISIBLETO

CLIENTS

VISIBLETO

CLIENTS

1

1 2: enqueue(M1)

1: enqueue(new M1)

3: dispatch()

loop { m = act_queue_.dequeue() if (m.guard()) m.call()}

Servant1

m1()m2()m3()

ActivationQueue

enqueue()dequeue()

1

1

nMethodRequest

guard()call()4: m1()

1 1

M1

M3

M2

There are six key participants in the Active Object pattern:

Proxy

� A Proxy [2, 5] provides an interface that allows clientsto invoke publically accessible methods on an Ac-tive Object using standard, strongly-typed program-ming language features, rather than passing loosely-typed messages between threads. When a client invokesa method defined by the Proxy, this triggers the con-struction and queueing of a Method Request object ontothe Scheduler’s Activation Queue, all of which occursin the client’s thread of control.

2

Method Request

� A Method Request is used to passcontext informationabout a specific method invocation on a Proxy, suchas method parameters and code, from the Proxy to aScheduler running in a separate thread. An abstractMethod Request class defines an interface for execut-ing methods of an Active Object. The interace alsocontainsguardmethods that can be used to determinewhen a Method Request’s synchronization constraintsare met. For every Active Object method offered bythe Proxy that requires synchronized access in its Ser-vant, the abstract Method Request class is subclassed tocreate a concrete Method Request class. Instances ofthese classes are created by the proxy when its methodsare invoked and contain the specific context informa-tion necessary to execute these method invocations andreturn any results back to clients.

Activation Queue

� An Activation Queue maintains a bounded buffer ofpending Method Requests created by the Proxy. Thisqueue keeps track of which Method Requests to exe-cute. It also decouples the client thread from the servantthread so the two threads can run concurrently.

Scheduler

� A Scheduler runs in a different thread than its clients,managing an Activation Queue of Method Requeststhat are pending execution. A Scheduler decides whichMethod Request to dequeue next and execute on theServant that implements this method. This schedul-ing decision is based on various criteria, such asor-dering, e.g., the order in which methods are insertedinto the Activation Queue, andsynchronization con-straints, e.g., the fulfillment of certain properties or theoccurrence of specific events, such as space becomingavailable for new elements in a bounded data structure.A Scheduler typically evaluates synchronization con-straints by using method request guards.

Servant

� A Servant defines the behavior and state that is be-ing modeled as an Active Object. Servants implementthe methods defined in the Proxy and the correspond-ing Method Requests. A Servant method is invokedwhen its corresponding Method Request is executed bya Scheduler; thus, Servants execute in the Scheduler’sthread of control. Servants may provide other methodsused by Method Requests to implement their guards.

Future

� A Future [7, 8] allows a client to obtain the results ofmethod invocations after the Servant finishes executingthe method. When a client invokes methods through a

Proxy, a Future is returned immediately to the client.The Future reserves space for the invoked method tostore its results. When a client wants to obtain these re-sults, it can “rendezvous” with the Future, either block-ing or polling until the results are computed and storedinto the Future.

8 Dynamics

The following figure illustrates the three phases of collabo-rations in the Active Object pattern:

INVOKE

DEQUEUE SUITABLE

METHOD REQUEST

RETURN RESULT

EXECUTE

Client

Proxy ActivationQueue

ME

TH

OD

OB

JE

CT

ME

TH

OD

OB

JE

CT

CO

NS

TR

UC

TIO

NC

ON

ST

RU

CT

ION

SC

HE

DU

LIN

GS

CH

ED

UL

ING

//E

XE

CU

TIO

NE

XE

CU

TIO

NC

OM

PL

ET

ION

CO

MP

LE

TIO

N

m1()

ServantServant

Scheduler Scheduler

CREATE METHODCREATE METHODREQUESTREQUEST

reply_to_future()

future()RETURN FUTURERETURN FUTURE

INSERT INTOINSERT INTO ACTIVATION QUEUE ACTIVATION QUEUE

enqueue(new M1)

dequeue(M1)

enqueue(M1)

M1

call()

dispatch(M1)

m1()

guard()

1. Method Request construction and scheduling: In thisphase, the client invokes a method on the Proxy. This trig-gers the creation of a Method Request, which maintains theargument bindings to the method, as well as any other bind-ings required to execute the method and return its results.The Proxy then passes the Method Request to the Scheduler,which enqueues it on the Activation Queue. If the method isdefined as atwo-way[6], a binding to a Future is returned tothe client that invoked the method. No Future is returned if amethod is defined as aoneway, i.e., it has no return values.

2. Method execution: In this phase, the Scheduler runscontinuously in a different thread than its clients. Within thisthread, the Scheduler monitors the Activation Queue and de-termines which Method Request(s) have become runnable,e.g., when their synchronization constraints are met. When aMethod Request becomes runnable, the Scheduler dequeuesit, binds it to the Servant, and dispatches the appropriatemethod on the Servant. When this method is called, it canaccess/update the state of its Servant and create its result(s).

3. Completion: In the final phase, the results, if any, arestored in the Future and the Scheduler continues to monitorthe Activation Queue for runnable Method Requests. Aftera two-way method completes, clients can retrieve its resultsby rendezvousing with the Future. In general, any clientsthat rendezvous with the Future can obtain its results. TheMethod Request and Future are deleted or garbage collectedwhen they are no longer referenced.

3

9 Implementation

This section explains the steps involved in building a concur-rent application using the Active Object pattern. The appli-cation implemented using the Active Object pattern is a por-tion of the Gateway from Section 3. Figure 2 illustrates thestructure and participants in this example. The example in

MQ_ProxyMQ_Proxy

put (msg)Future get()

MQMQSchedulerScheduler

dispatch()enqueue()

loop { m = act_queue_.dequeue() if (m.guard()) m.call()}

MQMQServantServantINVISIBLEINVISIBLE

TOTO

CLIENTSCLIENTS

VISIBLEVISIBLETOTO

CLIENTSCLIENTS

1: enqueue(Put)2: enqueue

(new Put)

3: dispatch()

put()get()

ActivationActivationQueueQueue

enqueue()dequene()

PutPut

GetGet

MethodMethodRequestRequest

guard()call()

nn

11

4: put()

11 11

Figure 2: Implementing a Message Queue as an Active Ob-ject forConsumer Handler s

this section uses reusable components from the ACE frame-work [9]. ACE provides a rich set of reusable C++ wrappersand framework components that perform common commu-nication software tasks across a wide range of OS platforms.

1. Implement the Servant: A Servant defines the behav-ior and state that is being modeled as an Active Object. Themethods a Servant implements are accessible by clients via aProxy. In addition, a Servant may contain other methods thatMethod Requests can use to implement guards that allow aScheduler to evaluate run-time synchronization constraints.These constraints determine the order in which a Schedulerdispatches Method Requests.

In our Gateway example, the Servant is a message queuethat buffers messages that are pending delivery to con-sumers. For each remote consumer, there is aConsumerHandler that contains a TCP connection to the consumerprocess. In addition, aConsumer Handler contains amessage queue model as an Active Object and implementedwith anMQServant . EachConsumer Handler ’s Ac-tive Object message queue stores messages passed from sup-plier to the Gateway while they are waiting to be sent to theirremote consumer. The following class provides an interfacefor this Servant:

class MQ_Servant{public:

MQ_Servant (size_t mq_size);

// Message queue implementation operations.void put_i (const Message &msg);Message get_i (void);

// Predicates.bool empty_i (void) const;bool full_i (void) const;

private:// Internal Queue representation, e.g., a// circular array or a linked list, etc.

};

Theput i andget i methods implement the insertionand removal operations on the queue, respectively. In ad-dition, the servant defines twopredicates, empty i andfull i , that distinguish three internal states: (1) empty, (2)full, and (3) neither empty nor full. These predicates are usedin the implementation of the Method Requestguard meth-ods, which allow the Scheduler to enforce run-time synchro-nization constraints that dictate the order in whichput iandget i methods are called on a Servant.

Note how theMQServant class is designed so that syn-chronization mechanisms remain external to the Servant.For instance, in our Gateway example, the methods in theMQServant class do not include any code that imple-ments synchronization. This class only provides methodsthat implement the Servant’s functionality and check its in-ternal state. This design avoids theinheritance anomaly[10, 11, 12, 13] problem, which inhibits the reuse of Servantimplementations if subclasses require different synchroniza-tion policies. Thus, a change to the synchronization con-straints of the Active Object need not affect its servant im-plementation.

2. Implement the Proxy and Method Requests: TheProxy provides clients with an interface to the Servant’smethods. For each method invocation by a client, the Proxycreates a Method Request. A Method Request is an abstrac-tion for the context1 of a method. This context typically in-cludes the method parameters, a binding to the Servant themethod will be applied to, a Future for the result, and thecode for the Method Request’scall method.

In our Gateway example, theMQProxy provides an ab-stract interface to theMQServant defined in Step 1. Thismessage queue is used by aConsumer Handler to queuemessages for delivery to consumers, as shown in Figure 2. Inaddition, theMQProxy is a factory that constructs instancesof Method Requests and passes them to a Scheduler, whichqueues them for subsequent execution in a separate thread.The C++ implementation ofMQProxy is shown below:

class MQ_Proxy{public:

// Bound the message queue size.enum { MAX_SIZE = 100 };

MQ_Proxy (size_t size = MAX_SIZE): scheduler_ (new MQ_Scheduler (size)),

servant_ (new MQ_Servant (size)) {}

// Schedule <put> to execute on the active object.void put (const Message &m) {

Method_Request *method_request =

1This context is often called aclosure.

4

new Put (servant_, m);scheduler_->enqueue (method_request);

}

// Return a Message_Future as the ‘‘future’’// result of an asynchronous <get>// method on the active object.Message_Future get (void) {

Message_Future result;

Method_Request *method_request =new Get (servant_, result);

scheduler_->enqueue (method_request);return result;

}

// ... empty() and full() predicate implementations ...

protected:// The Servant that implements the// Active Object methods.MQ_Servant *servant_;

// A scheduler for the Message Queue.MQ_Scheduler *scheduler_;

};

Each method of anMQProxy transforms its invoca-tion into a Method Request and passes the request to itsMQScheduler , which enqueues it for subsequent acti-vation. A Method Request base class defines virtualguard and call methods that are used by its Schedulerto determine if a Method Request can be executed and toexecute the Method Request on its Servant, respectively, asfollows:

class Method_Request{public:

// Evaluate the synchronization constraint.virtual bool guard (void) const = 0;

// Implement the method.virtual void call (void) = 0;

};

The methods in this class must be defined by subclasses, onesubclass for each method defined in the Proxy. The ratio-nale for defining these two methods is to provide Sched-ulers with a uniform interface to evaluate and execute con-creteMethod Request s. Thus, Schedulers can be decou-pled from specific knowledge of how to evaluate the syn-chronization constraints or trigger the execution of concreteMethod Request .

For instance, when a client invokes theput method onthe Proxy in our Gatway example, this method is trans-formed into an instance of thePut subclass, which inher-its from Method Request and contains a pointer to theMQServant , as follows:

class Put : public Method_Request{public:

Put (MQ_Servant *rep,Message arg)

: servant_ (rep), arg_ (arg) {}

virtual bool guard (void) const {

// Synchronization constraint: only allow// <put_i> calls when the queue is not full.return !servant_->full_i ();

}

virtual void call (void) {// Insert message into the servant.servant_->put_i (arg_);

}

private:MQ_Servant *servant_;Message arg_;

};

Note how theguard method uses theMQServant ’sfull i predicate to implement a synchronization constraintthat allows the Scheduler to determine when thePut methodrequest can execute. When aPut method request can be ex-ecuted, the Scheduler invokes itscall hook method. Thiscall hook uses its run-time binding to theMQServantto invoke the Servant’sput i method. This method is ex-ecuted in the context of that Servant and does not requireany explicit serialization mechanisms since the Schedulerenforces all the necessary synchronization constraints via theMethod Requestguard s.

The Proxy also transforms theget method into an in-stance of theGet class, which is defined as follows:

class Get : public Method_Request{public:

Get (MQ_Servant *rep,const Message_Future &f)

: servant_ (rep), result_ (f) {}

bool guard (void) const {// Synchronization constraint:// cannot call a <get_i> method until// the queue is not empty.return !servant_->empty_i ();

}

virtual void call (void) {// Bind the dequeued message to the// future result object.result_ = servant_->get_i ();

}

private:MQ_Servant *servant_;

// Message_Future result value.Message_Future result_;

};

For every two-way method in the Proxy that returns avalue, such as theget i method in our Gateway example, aMessage Future is returned to the client thread that callsit, as shown in implementation Step 4 below. The client maychoose to evaluate theMessage Future ’s value immedi-ately, in which case the client blocks until the method requestis executed by the scheduler. Conversely, the evaluation ofa return result from a method invocation on an Active Ob-ject can be deferred, in which case the client thread and thethread executing the method can proceed asynchronously.

3. Implement the Activation Queue: Each Method Re-quest is enqueued on an Activation Queue. This is typically

5

implemented as a thread-safe bounded-buffer that is sharedbetween the client threads and the thread where the Sched-uler and Servant run. An Activation Queue also provides aniterator that allows the Scheduler to traverse its elements inaccordance with the Iterator pattern [5].

The follow-ing C++ code illustrates how theActivation Queue isused in the Gateway:

class Activation_Queue{public:

// Block for an "infinite" amount of time// waiting for <enqueue> and <dequeue> methods// to complete.const int INFINITE = -1;

// Define a "trait".typedef Activation_Queue_Iterator

iterator;

// Constructor creates the queue with the// specified high water mark that determines// its capacity.Activation_Queue (size_t high_water_mark);

// Insert <method_request> into the queue, waiting// up to <msec_timeout> amount of time for space// to become available in the queue.void enqueue (Method_Request *method_request,

long msec_timeout = INFINITE);

// Remove <method_request> from the queue, waiting// up to <msec_timeout> amount of time for a// <method_request> to appear in the queue.void dequeue (Method_Request *method_request,

long msec_timeout = INFINITE);

private:// Synchronization mechanisms, e.g., condition// variables and mutexes, and the queue// implementation, e.g., an array or a linked// list, go here.// ...

};

Theenqueue anddequeue methods provide a “bounded-buffer producer/consumer” concurrency model that al-lows multiple threads to simultaneously insert and removeMethod Request s without corrupting the internal state ofanActivation Queue. One or more client threads playthe role of producers, enqueueingMethod Request s via aProxy. The Scheduler thread plays the role of consumer, de-queueingMethod Request s when theirguard s evaluateto “true” and invoking theircall hooks to execute Servantmethods.

The Activation Queue is designed as a bounded-buffer using condition variables and mutexes [14]. There-fore, the Scheduler thread will block formsec timeoutamount of time when trying to removeMethod Requestsfrom an emptyActivation Queue. Likewise, clientthreads will block for up tomsec timeout amount of timewhen they try to insert onto a fullActivation Queue,i.e., a queue whose currentMethod Request count equalsits high water mark. If anenqueue method times out, con-trol returns to the client thread and the method is not exe-cuted.

4. Implement the Scheduler: A Scheduler maintains theActivation Queue and executes pending Method Requestswhose synchronization constraints are met. The public in-terface of a Scheduler typically provides one method forthe Proxy to enqueue Method Requests into the ActivationQueue and another method that dispatches method requestson the Servant. These methods run in separate threads,i.e.,the Proxy runs in different threads than the Scheduler andServant, which run in the same thread.

In our Gateway example, we define anMQSchedulerclass, as follows:

class MQ_Scheduler{public:

// Initialize the Activation_Queue to have the// specified capacity and make the Scheduler// run in its own thread of control.MQ_Scheduler (size_t high_water_mark);

// ... Other constructors/destructors, etc.,

// Insert the Method Request into// the Activation_Queue. This method// runs in the thread of its client, i.e.,// in the Proxy’s thread.void enqueue (Method_Request *method_request) {

act_queue_->enqueue (method_request);}

// Dispatch the Method Requests on their Servant// in the Scheduler’s thread.virtual void dispatch (void);

protected:// Queue of pending Method_Requests.Activation_Queue *act_queue_;

// Entry point into the new thread.static void *svc_run (void *arg);

};

The Scheduler executes itsdispatch method in a dif-ferent thread of control than its client threads. These clientthreads make the Proxy enqueueMethod Request s inthe Scheduler’sActivation Queue. The Schedulermonitors itsActivation Queue in its own thread, se-lecting a Method Request whose guard evaluates to“true,” i.e., whose synchronization constraints are met. ThisMethod Request is then executed by invoking itscallhook method. Note that multiple client threads can sharethe same Proxy. The Proxy methods need not be thread-safe since the Scheduler and Activation Queue handle con-currency control.

For instance, in our Gateway example, the constructor ofMQScheduler initializes theActivation Queue andspawns a new thread of control to run theMQScheduler ’sdispatch method, as follows:

MQ_Scheduler (size_t high_water_mark): act_queue_ (new Activation_Queue

(high_water_mark)){

// Spawn a separate thread to dispatch// method requests.Thread_Manager::instance ()->spawn (svc_run,

this);}

6

This new thread executes thesvc run static method, whichis simply an adapter that calls thedispatch method, asfollows:

void *MQ_Scheduler::svc_run (void *args){

MQ_Scheduler *this_obj =reinterpret_cast<MQ_Scheduler *> (args);

this_obj->dispatch ();}

Thedispatch method determines the order thatPut andGet method requests are processed based on the underly-ing MQServant predicatesempty i andfull i . Thesepredicates reflect the state of the Servant, such as whetherthe message queue is empty, full, or neither. By evaluatingthese predicate constraints via the Method Requestguardmethods, the Scheduler can ensure fair shared access to theMQServant , as follows:

virtual voidMQ_Scheduler::dispatch (void){

// Iterate continuously in a// separate thread.for (;;) {

Activation_Queue::iterator i;

// The iterator’s <begin> call blocks// when the <Activation_Queue> is empty.for (i = act_queue_->begin ();

i != act_queue_->end ();i++) {

// Select a Method Request ‘mr’// whose guard evaluates to true.Method_Request *mr = *i;

if (mr->guard ()) {// Remove <mr> from the queue first// in case <call> throws an exception.act_queue_->dequeue (mr);mr->call ();delete mr;

}}

}}

In our Gateway example, thedispatch implementationof theMQScheduler class continuously executes the nextMethod Request whoseguard evaluates to true. Sched-uler implementations can be more sophisticated, however,and may contain variables that represent the synchronizationstate of the Servant. For example, to implement a multiple-readers/single-writer synchronization policy several countervariables can be stored in the Scheduler to keep track of thenumber of read and write requests. The Scheduler can usethese counts to determine when a single writer can proceed,that is, when the current number of readers is 0 and no otherwriter is currently running. Note that the counter values areindependent of the Servant’s state since they are only used bythe Scheduler to enforce the correct synchronization policyon behalf of the Servant.

5. Determine rendezvous and return value policies: Therendezvous policy determines how clients obtain return val-ues from methods invoked on active objects. A rendezvouspolicy is required since Active Object servants do not executein the same thread as clients that invoke their methods. Im-plementations of the Active Object pattern typically choosefrom the following rendezvous and return value policies:

1. Synchronous waiting– Block the client thread syn-chronously in the Proxy until the Method Request isdispatched by the Scheduler and the result is computedand stored in the future.

2. Synchronous timed wait– Block only for a boundedamount of time and fail the result of a two-way callis not returned within the allocated time period. If thetimeout is zero the client thread “polls,”i.e., it returns tothe caller without queueing the Method Request if theScheduler cannot dispatch it immediately.

3. Asynchronous– Queue the Method Request and returncontrol to the client thread immediately. If the methodis a two-way call that produces a result then some formof Future mechanism must be used to provide synchro-nized access to the value (or to the error status if themethod call fails).

The Future construct allows two-way asynchronous invo-cations that return a value to the client. When a Servant com-pletes the method execution, it acquires a write lock on theFuture and updates the Future with a result value. Any clientthreads that are currently blocked waiting for the result valueare awakened and may access the result value concurrently.A Future object can be garbage collected after the writer andall readers no longer reference the Future. In languages likeC++, which do not support garbage collection natively, theFuture objects can be reclaimed when they are no longer inuse via idioms like Counter Pointer [2].

In our Gateway example, theget method invoked on theMQProxy ultimately results in theGet::call methodbeing dispatched by theMQScheduler , as shown in Step2 above. Since theMQProxy get method returns a value, aMessage Future is returned when the client calls it. TheMessage Future is defined as follows:

class Message_Futurepublic:

// Copy constructor binds <this> and <f> to the// same <Message_Future_Rep>, which is created if// necessary.Message_Future (const Message_Future &f);

// Constructor that initializes <Message_Future> to// point to <Message> <m> immediately.Message_Future (const Message &m);

// Assignment operator that binds <this> and <f>// to the same <Message_Future_Rep>, which is// created if necessary.void operator= (const Message_Future &f);

// ... other constructors/destructors, etc.,

// Type conversion, which blocks

7

// waiting to obtain the result of the// asynchronous method invocation.operator Message ();

};

TheMessage Future is implemented using the CountedPointer idiom [2]. This idiom simplifies memory manage-ment for dynamically allocated C++ objects by using a refer-ence countedMessage Future Rep bodythat is accessedsolely through theMessage Future handle.

In general, a client can obtain theMessage result valuefrom aMessage Future object in either of the followingsways:

� Immediate evaluation: The client may choose toevaluate theMessage Future ’s value immediately. Forexample, a GatewayConsumer Handler running in aseparate thread may choose to block until new messages ar-rive from suppliers, as follows:

MQ_Proxy mq;// ...

// Conversion of Message_Future from the// get() method into a Message causes the// thread to block until a message is// available.Message msg = mq.get ();

// Transmit message to the consumer.send (msg);

� Deferred evaluation: The evaluation of a return re-sult from a method invocation on an Active Object canbe deferred. For example, if messages are not avail-able immediately, aConsumer Handler can store theMessage Future return value frommqand perform other“bookkeeping” tasks, such as exchangingkeep-alive mes-sagesto ensure its consumer is still active. When theConsumer Handler is done with these tasks it can blockuntil a message arrives from suppliers, as follows:

// Obtain a future (does not block the client).Message_Future future = mq.get ();

// Do something else here...

// Evaluate future in the conversion operator;// may block if the result is not available yet.Message msg = Message (future);

10 Example Resolved

Internally, the Gateway software containsSupplier andConsumer Handler s that act as local proxies [2, 5] forremote suppliers and consumers, respectively. As shown inFigure 3,Supplier Handlers receive messages fromremote suppliers, inspect address fields in the messages, anduse the address as a key into aRouting Table that iden-tifies which remote consumer should receive the message.The Routing Table maintains a map ofConsumer

GATEWAYGATEWAY

Supplier SupplierHandlerHandler

Consumer ConsumerHandlerHandler

Message MessageQueueQueue

OUTGOING

MESSAGES

Routing RoutingTableTable

INCOMING

MESSAGES

OUTGOING

MESSAGES

2: find_route (msg)2: find_route (msg)3: put (msg)

CONSUMERCONSUMER

SUPPLIERSUPPLIER

CONSUMERCONSUMER

SUPPLIERSUPPLIER

Consumer ConsumerHandlerHandler

Message MessageQueueQueue

INCOMING

MESSAGES

Supplier SupplierHandlerHandler

1: recv (msg)1: recv (msg)

Figure 3: Communication Gateway

Handler s, each of which is responsible for delivering mes-sages to its remote consumer over a separate TCP connec-tion.

To handle flow control over various TCP connections,eachConsumer Handler contains aMessage Queueimplemented using the Active Object described in Section 9.TheConsumer Handler class is defined as follows:

class Consumer_Handler{public:

Consumer_Handler (void);

// Put the message into the queue.void put (const Message &msg) {

message_queue_.put (msg);}

private:// Proxy to the Active Object.MQ_Proxy message_queue_;

// Connection to the remote consumer.SOCK_Stream connection_;

// Entry point into the new thread.static void *svc_run (void *arg);

};

Supplier Handler s running in theirown threadsput messages into the appropriateConsumerHandler ’s Message Queue , as follows:

Supplier_Handler::route_message (const Message &msg){

// Locate the appropriate consumer based on the// address information in the Message.Consumer_Handler *ch =

routing_table_.find (msg.address ());

// Put the Message into the Consumer Handler’s queue.ch->put (msg);

};

8

To process the messages placed into its message queue,each Consumer Handler spawns a separate thread ofcontrol in its constructor, as follows:

Consumer_Handler::Consumer_Handler (void){

// Spawn a separate thread to get messages// from the message queue and send them to// the consumer.Thread_Manager::instance ()->spawn (svc_run,

this);}

This new thread executes thesvc run method, whichgets the messages placed into the queue bySupplierHandler threads and sends them to the consumer over theTCP connection, as follows:

void *Consumer_Handler::svc_run (void *args){

Consumer_Handler *this_obj =reinterpret_cast<Consumer_Handler *> (args);

for (;;) {// Conversion of Message_Future from the// get() method into a Message causes the// thread to block until a message is// available.Message msg = this_obj->message_queue_.get ();

// Transmit message to the consumer.this_obj->connection_.send (msg);

}}

Since the message queue is implemented as an Ac-tive Object thesend operation can block in any givenConsumer Handler object without affecting the qualityof service of otherConsumer Handler s.

11 Variants

The following are variations of the Active Object pattern.

Integrated Scheduler: To reduce the number of compo-nents needed to implement the Active Object pattern, theroles of the Proxy and Servant are often integrated into theScheduler component, though servants still execute in a dif-ferent thread than the proxies. Moreover, the transformationof the method call into a Method Request can also be inte-grated into the Scheduler. For instance, the following is an-other way to implement the Message Queue example usingan integrated Scheduler:

class MQ_Schedulerpublic:

MQ_Scheduler (size_t size): act_queue_ (new Activation_Queue (size))

{}

// ... other constructors/destructors, etc.,

void put (const Message &msg) {Method_Request *method_request =

// The <MQ_Scheduler> is the servant.new Put (this, msg);

act_queue_->enqueue (method_request);}

Message_Future get (void) {Message_Future result;

Method_Request *method_request =// The <MQ_Scheduler> is the servant.new Get (this, result);

act_queue_->enqueue (method_request);return result;

}

// ...private:

// Message queue servant operations.void put_i (const Message &msg);Message get_i (void);

// Predicates.bool empty_i (void) const;bool full_i (void) const;

Activation_Queue *act_queue_;// ...

};

By centralizing where Method Requests are generated, thepattern implementation can be simplified since there arefewer components. The drawback, of course, is that theScheduler must know the type of the Servant and Proxy,which makes it hard to reuse a Scheduler for different typesof Active Objects.

Message passing: A further refinement of the integratedScheduler variant is to remove the Proxy and Servant alto-gether and use directmessage passingbetween the clientthread and the Scheduler thread, as follows:

class Schedulerpublic:

Scheduler (size_t size): act_queue_ (new Activation_Queue (size))

{}

// ... other constructors/destructors, etc.,

// Enqueue a Message Request in the thread of// the client.void enqueue (Message_Request *message_request) {

act_queue_->enqueue (message_request);}

// Dispatch Message Requests in the thread of// the Scheduler.virtual void dispatch (void) {

Message_Request *mr;

// Block waiting for next request to arrive.while (act_queue_->dequeue (mr)) {

// Process the message request <mr>.}

}}

protected:Activation_Queue *act_queue_;// ...

};

In this design, there is no Proxy, so clients sim-ply create an appropriate type ofMessage Request

9

and call enqueue , which inserts the request into theActivation Queue. Likewise, there is no Servant, sothedispatch method running in theScheduler ’s threadsimply dequeues the nextMessage Request and pro-cesses the request according to its type.

In general, it is easier to develop a message passing mech-anism than it is to develop an Active Object since there arefewer components to develop. However, message passingis typically more tedious and error-prone since applicationdevelopers are responsible for programming the Proxy andServant logic, rather than letting the Active Object develop-ers write this code.

Polymorphic futures: A Polymorphic Future [15] allowsparameterization of the eventual result type represented bythe Future and enforces the necessary synchronization. Inparticular, a Polymorphic Future result value provides write-once, read-many synchronization. Whether a client blockson a future depends on whether or not a result value hasbeen computed. Hence, a Polymorphic Future is partly areader-writer condition synchronization pattern and partly aproducer-consumer synchronization pattern.

The following class illustrates a polymorphic future tem-plate in C++:

template <class T>class Future{

// This class implements a ‘single write, multiple// read’ pattern that can be used to return results// from asynchronous method invocations.

public:// Constructor.Future (void);

// Copy constructor that binds <this> and <r> to// the same <Future> representationFuture (const Future<T> &r);

// Destructor.˜Future (void);

// Assignment operator that binds <this> and// <r> to the same <Future>.void operator = (const Future<T> &r);

// Cancel a <Future>. Put the future into its// initial state. Returns 0 on success and -1// on failure.int cancel (void);

// Type conversion, which obtains the result// of the asynchronous method invocation.// Will block forever until the result is// obtained.operator T ();

// Check if the result is available.int ready (void);

private:Future_Rep<T> *future_rep_;// Future representation implemented using// the Counted Pointer idiom.

};

A client can use a polymorphic future as follows:

// Obtain a future (does not block the client).Future<Message> future = mq.get ();

// Do something else here...

// Evaluate future in the conversion operator;// may block if the result is not available yet.Message msg = Message (future);

Distributed Active Object: In this variant, a distributionboundary exists between the Proxy and the Scheduler, ratherthan a threading boundary, as with the conventional Ac-tive Object pattern. Therefore, the client-side Proxy playsthe role of astub, which is responsible for marshaling themethod parameters into a Method Request format that canbe transmitted across a network and executed by a Servant ina separate address space. In addition, this variant also typ-ically introduces the notion of a server-sideskeleton, whichperforms demarshaling on the Method Request parametersbefore they are passed to a Servant method in the server.

Thread pool: A thread pool is a generalization of Ac-tive Object that supports multiple Servants per Active Ob-ject. These Servants can offer the same services to increasethroughput and responsiveness. Every Servant runs in itsown thread and actively ask the Scheduler to assign a newrequest when it is ready with its current job. The Schedulerthen assigns a new job as soon as one is available.

12 Known Uses

The following are specific known uses of the Active Objectpattern:

CORBA ORBs: The Active Object pattern has been usedto implement concurrent ORB middleware frameworks, suchas CORBA [6] and DCOM [16]. For instance, the TAOORB [17] implements the Active Object pattern for its de-fault concurrency model [18]. In this design, CORBAstubs correspond to the Active Object pattern’s Proxies,which transform remote operation invocations into CORBARequest s. The TAO ORB Core’sReactor is the Sched-uler and the socket queues in the ORB Core correspond to theActivation Queues. Developers create Servants that executethe methods in the context of the server. Clients can eithermake synchronous two-way invocations, which block thecalling thread until the operation returns, or they can makeasynchronous method invocations, which return a Poller fu-ture object that can be evaluated at a later point [19].

ACE Framework: Reusable implementations of theMethod Request , Activation Queue , andFuturecomponents in the Active Object pattern are provided in theACE framework [9]. These components have been used toimplement many production distributed systems.

Siemens MedCom: The Active Object pattern is used inthe Siemens MedCom framework, which provides a black-box component-oriented framework for electronic medicalsystems [20]. MedCom employ the Active Object pattern

10

in conjunction with the Command Processor pattern to sim-plify client windowing applications that access patient infor-mation on various medical servers.

Siemens Call Center management system:This systemuses the thread pool variant of the Active Object pattern.

Actors: The Active Object pattern has been used to imple-ment Actors [21]. An Actor contains a set of instance vari-ables and behaviors that react to messages sent to an Actorby other Actors. Messages sent to an Actor are queued in theActor’s message queue. In the Actor model, messages areexecuted in order of arrival by the “current” behavior. Eachbehavior nominates a replacement behavior to execute thenext message, possibly before the nominating behavior hascompleted execution. Variations on the basic Actor modelallow messages in the message queue to be executed basedon criteria other than arrival order [22]. When the Active Ob-ject pattern is used to implement Actors, the Scheduler cor-responds to the Actor scheduling mechanism, Method Re-quest correspond to the behaviors defined for an Actor, andthe Servant is the set of instance variables that collectivelyrepresent the state of an Actor [23]. The Proxy is simply astrongly-typed mechanism used to pass a message to an Ac-tor.

13 Consequences

The Active Object pattern provides the following benefits:

Enhance application concurrency and simplify synchro-nization complexity: Concurrency is enhanced by allow-ing client threads and asynchronous method executions torun simultaneously. Synchronization complexity is simpli-fied by the Scheduler, which evaluates synchronization con-straints to guarantee serialized access to Servants, dependingon their state.

Transparently leverage available parallelism: If thehardware and software platforms support multiple CPUs ef-ficiently, this pattern can allow multiple active objects to ex-ecute in parallel, subject to their synchronization constraints.

Method execution order can differ from method invoca-tion order: Methods invoked asynchronously are executedbased on their synchronization constraints, which may differfrom their invocation order.

However, the Active Object pattern has the following liabil-ities:

Performance overhead: Depending on how the Scheduleris implemented,e.g., in user-space vs. kernel-space, con-text switching, synchronization, and data movement over-head may occur when scheduling and executing active objectmethod invocations. In general, the Active Object pattern ismost applicable on relatively coarse-grained objects. In con-trast, if the objects are very fine-grained, the performanceoverhead of active objects can be excessive, compared withother concurrency patterns such as Monitors.

Complicated debugging: It may be difficult to debug pro-grams containing active objects due to the concurrency andnon-determinism of the Scheduler. Moreover, many debug-gers do not support concurrent applications adequately.

14 See Also

The Monitor pattern ensures that only one method at a timeexecutes within a Passive Object, regardless of the number ofthreads that invoke this object’s methods concurrently. Mon-itors are generally more efficient than Active Objects sincethey incur less context switching and data movement over-head. However, it is harder to add a distribution boundarybetween client and server threads using the Monitor pattern.

The Reactor pattern [24] is responsible for demultiplexingand dispatching of multiple event handlers that are triggeredwhen it is possible to initiate an operation without blocking.This pattern is often used in lieu of the Active Object patternto schedule callback operations to passive objects. It canalso be used in conjunction of the Active Object pattern toform the Half-Sync/Half-Async pattern described in the nextparagraph.

The Half-Sync/Half-Async pattern [25] is an architecturalpattern that decouples synchronous I/O from asynchronousI/O in a system to simplify concurrent programming effortwithout degrading execution efficiency. This pattern typi-cally uses the Active Object pattern to implement the Syn-chronous task layer, the Reactor pattern [24] to implementthe Asynchronous task layer, and a Producer/Consumer pat-tern to implement the Queueing layer.

The Command Processor pattern [2] is similar to the Ac-tive Object pattern. Its intent is to separate the issuing ofrequests from their execution. A command processor, whichcorresponds to the scheduler, maintains pending service re-quests, which are implemented as Commands [5]. These areexecuted on suppliers, which correspond to servants. TheCommand Processor pattern does not focus on concurrency,however, and clients, the command processor, and suppli-ers reside in the same thread of control. Thus, there are noproxies that represent the servants to clients. Clients createcommands and pass them directly to the command processor.

The Broker pattern [2] has many of the same componentsas the Active Object pattern. In particular, clients access Bro-kers via Proxies and servers implement remote objects viaServants. The primary difference between the Broker pat-tern and the Active Object pattern is that there’s a distributionboundary between proxies and servants in the Broker patternvs. a threading boundary between proxies and servants in theActive Object pattern.

The Mutual Exclusion (Mutex) pattern [26] is a simplelocking pattern that is often used in lieu of Active Objectswhen implementing concurrent Passive Objects, also knownas Monitors. The Mutex pattern can occur in slightly differ-ent forms, such as a spin lock or a semaphore. The Mutexpattern can have various semantics, such as recursive mu-texes and priority inheritance mutexes.

11

Acknowledgements

The genesis for the Active Object pattern originated withGreg Lavender. Thanks to Frank Buschmann, Hans Rohn-ert, Martin Botzler, Michael Stal, Christa Schwanninger, andGreg Gallant for extensive comments that greatly improvedthe form and content of this version of the pattern descrip-tion.

References[1] D. C. Schmidt, “Acceptor and Connector: Design Patterns for

Initializing Communication Services,” inPattern Languagesof Program Design(R. Martin, F. Buschmann, and D. Riehle,eds.), Reading, MA: Addison-Wesley, 1997.

[2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, andM. Stal,Pattern-Oriented Software Architecture - A System ofPatterns. Wiley and Sons, 1996.

[3] D. C. Schmidt, “A Family of Design Patterns for Application-level Gateways,”The Theory and Practice of Object Systems(Special Issue on Patterns and Pattern Languages), vol. 2,no. 1, 1996.

[4] W. R. Stevens,TCP/IP Illustrated, Volume 1. Reading, Mas-sachusetts: Addison Wesley, 1993.

[5] E. Gamma, R. Helm, R. Johnson, and J. Vlissides,Design Pat-terns: Elements of Reusable Object-Oriented Software. Read-ing, MA: Addison-Wesley, 1995.

[6] Object Management Group,The Common Object RequestBroker: Architecture and Specification, 2.2 ed., Feb. 1998.

[7] R. H. Halstead, Jr., “Multilisp: A Language for Concur-rent Symbolic Computation,”ACM Trans. Programming Lan-guages and Systems, vol. 7, pp. 501–538, Oct. 1985.

[8] B. Liskov and L. Shrira, “Promises: Linguistic Support forEfficient Asynchronous Procedure Calls in Distributed Sys-tems,” inProceedings of the SIGPLAN’88 Conference on Pro-gramming Language Design and Implementation, pp. 260–267, June 1988.

[9] D. C. Schmidt, “ACE: an Object-Oriented Framework forDeveloping Distributed Applications,” inProceedings of the6th USENIX C++ Technical Conference, (Cambridge, Mas-

sachusetts), USENIX Association, April 1994.

[10] P. America, “Inheritance and Subtyping in a Parallel Object-Oriented Language,” inECOOP’87 Conference Proceedings,pp. 234–242, Springer-Verlag, 1987.

[11] D. G. Kafura and K. H. Lee, “Inheritance in Actor-Based Con-current Object-Oriented Languages,” inECOOP’89 Confer-ence Proceedings, pp. 131–145, Cambridge University Press,1989.

[12] S. Matsuoka, K. Wakita, and A. Yonezawa, “Analysis ofInheritance Anomaly in Concurrent Object-Oriented Lan-guages,”OOPS Messenger, 1991.

[13] M. Papathomas, “Concurrency Issues in Object-OrientedLanguages,” inObject Oriented Development(D. Tsichritzis,ed.), pp. 207–245, Centre Universitaire D’Informatique, Uni-versity of Geneva, 1989.

[14] W. R. Stevens,UNIX Network Programming, Second Edition.Englewood Cliffs, NJ: Prentice Hall, 1997.

[15] R. G. Lavender and D. G. Kafura, “A Polymorphic Fu-ture and First-Class Function Type for Concurrent Object-Oriented Programming in C++,” inForthcoming, 1995.http://www.cs.utexas.edu/users/lavender/papers/futures.ps.

[16] D. Box, Essential COM. Addison-Wesley, Reading, MA,1997.

[17] D. C. Schmidt, D. L. Levine, and S. Mungee, “The Design andPerformance of Real-Time Object Request Brokers,”Com-puter Communications, vol. 21, pp. 294–324, Apr. 1998.

[18] D. C. Schmidt, “Evaluating Architectures for Multi-threadedCORBA Object Request Brokers,”Communications of theACM special issue on CORBA, vol. 41, Oct. 1998.

[19] Object Management Group,CORBA Messaging Specifica-tion, OMG Document orbos/98-05-05 ed., May 1998.

[20] P. Jain, S. Widoff, and D. C. Schmidt, “The Design and Per-formance of MedJava – Experience Developing Performance-Sensitive Distributed Applications with Java,”IEE/BCS Dis-tributed Systems Engineering Journal, 1998.

[21] G. Agha,A Model of Concurrent Computation in DistributedSystems. MIT Press, 1986.

[22] C. Tomlinson and V. Singh, “Inheritance and Synchronizationwith Enabled-Sets,” inOOPSLA’89 Conference Proceedings,pp. 103–112, Oct. 1989.

[23] D. Kafura, M. Mukherji, and G. Lavender, “ACT++: A ClassLibrary for Concurrent Programming in C++ using Actors,”Journal of Object-Oriented Programming, pp. 47–56, Octo-ber 1992.

[24] D. C. Schmidt, “Reactor: An Object Behavioral Pattern forConcurrent Event Demultiplexing and Event Handler Dis-patching,” in Pattern Languages of Program Design(J. O.Coplien and D. C. Schmidt, eds.), pp. 529–545, Reading, MA:Addison-Wesley, 1995.

[25] D. C. Schmidt and C. D. Cranor, “Half-Sync/Half-Async: anArchitectural Pattern for Efficient and Well-structured Con-current I/O,” in Proceedings of the2nd Annual Conferenceon the Pattern Languages of Programs, (Monticello, Illinois),pp. 1–10, September 1995.

[26] Paul E. McKinney, “A Pattern Language for Parallelizing Ex-isting Programs on Shared Memory Multiprocessors,” inPat-tern Languages of Program Design(J. O. Coplien, J. Vlis-sides, and N. Kerth, eds.), Reading, MA: Addison-Wesley,1996.

12