Active Object an Object Behavioral Pattern for Concurrent Programming R. Greg Lavender Douglas C. Schmidt [email protected] [email protected] ISODE Consortium Inc. Department of Computer Science Austin, TX Washington University, St. Louis An earlier version of this paper appeared in a chapter in the book ªPattern Languages of Program Design 2º ISBN 0-201-89527-7, edited by John Vlissides, Jim Coplien, and Norm Kerth published by Addison-Wesley, 1996. : Output : Input Handler Handler : Routing Table : Message Abstract Queue This paper describes the Active Object pattern, which decou- 3: enqueue(msg) ples method execution from method invocation in order to : Output 2: find_route(msg) simplify synchronized access to a shared resource by meth- Handler ods invoked in different threads of control. The Active Object : Message : Input pattern allows one or more independent threads of execution Queue Handler 1: recv(msg) to interleave their access to data modeled as a single ob- ject. A broad class of producer/consumer and reader/writer OUTGOING OUTGOING MESSAGES GATEWAY problems are well-suited to this model of concurrency. This MESSAGES pattern is commonly used in distributed systems requiring INCOMING INCOMING multi-threaded servers. In addition,client applications (such MESSAGES MESSAGES as windowing systems and network browsers), are increas- DST DST ingly employing active objects to simplify concurrent, asyn- SRC SRC chronous network operations. 1 Intent Figure 1: Connection-Oriented Gateway The Active Object pattern decouples method execution from method invocation in order to simplify synchronized access to a shared resource by methods invoked in different threads [2]. Sources and destinationscommunicate with the Gateway of control. using TCP connections. Internally, the Gateway contains asetofInput and Output Handler objects. Input Handlers receive messages from sources and use address 2 Also Known As ®elds in a message to determine the appropriate Output Handlers associated with the destination. The Output Concurrent Object, Actor, Serializer. Handler then delivers the message to the destination. Since communication between the sources, destinations, 3 Motivation and Gateway use TCP, Output Handlers may encounter ¯ow control from the transport layer. Connection-oriented To illustrate the Active Object pattern, consider the design protocols like TCP use ¯ow control to ensure that a fast of a connection-oriented Gateway. A Gateway decouples source does not produce data faster than a slow destination cooperating components in a distributed system and allows (or slow network) can buffer and consume the data. them to interact without having direct dependencies among To reduce end-to-end delay, an Output Handler ob- each other [1]. For example, the Gateway shown in Fig- ject must not block the entire Gateway waiting for ¯ow con- ure 1 routes messages from one or more source processes trol to abate on any single connection to a destination. One to one or more destination processes in a distributed system way to ensure this is to design the Gateway as a single- 1 threaded reactive state machine that uses asynchronous net- shared resource and (2) depend on the state of the re- work I/O. This design typically combines the Reactor pat- source (e.g., full vs. empty vs. neither). The Active tern [3], non-blocking sockets, and a set of message queues Object pattern makes is simple to program this class of (one per Output Handler). The Reactor pattern and the ªproducer/consumerº application. non-blocking sockets provide a single-threaded cooperative Take advantage of parallelism ± the Gateway can trans- event loop model of programming. The Reactor demulti- parently take advantage of the inherent concurrency plexes ªok to sendº and ªok to receiveº events to multiple between Input and Output Handler to improve Input Output Handler and objects. These handlers performance on multi-processor platforms. For exam- use non-blocking sends and receives to prevent the Gateway ple, the processing at Output Handlers can execute Output from blocking. The message queues are used by concurrently with Input Handlers that pass them Handlers to store messages in FIFO order until they can messages to be delivered. be delivered when ¯ow control abates. It is possible to build robust single-threaded connection- The structure of the Gateway application implemented us- oriented Gateways using the approach outlined above. There ing the Active Object pattern is illustrated in the following are several drawbacks with this approach, however: Booch class diagram: Complicated concurrent programming ± subtle pro- gramming is required to ensure that Output Handlers in the Gateway never block while routing loop { messages to their destinations. Otherwise, one misbe- Output m = actQueue.remove() Handler dispatch (m) having output connection can cause the entire Gateway Scheduler } put (msg) to block inde®nitely. dispatch() put'() Method Does not alleviate performance bottlenecks ± the use of single-threading does not take advantage of parallelism Object Queue insert() available from the underlying hardware and software remove() platform. Since the entire Gateway runs in a single Output Output thread of control it is not possible to transparently alle- Handler State Handler viate performance bottlenecks by running the system on Operations a multi-processor. A more convenient, and potentially more ef®cient, way to develop a connection-oriented Gateway is to use the Active Object pattern. This pattern enables a method to execute in a different thread than the one that invoked the method 4 Applicability originally. In contrast, passive objects execute in the same thread as the object that called a method on the passive object. Use the Active Object pattern when: Implementing Output Handlers as active objects in the Gateway enables them to block independently, without The design and implementationof a concurrent program adversely affecting each other or the Input Handlers. can be simpli®ed ± concurrent programs can often be The active object Gateway design resolves the following simpli®ed if the thread of control of an object O that forces: executes a method can be decoupled from the thread of control of objects that invoke methods on O . Simplify ¯ow control ± since an Output Handler Multiple threads of control require synchronized access active object has its own thread of control, it can block to shared data ± the Active Object pattern shields ap- waiting for ¯ow control to abate. If an Output plications from low-level synchronization mechanisms, Handler active object is blocked due to ¯ow con- rather than having them acquire and release locks ex- trol,Input Handler objectscan still insert messages plicitly. onto the message queue associated with the Output Handler. After completing its current send, an The order of method execution can differ from the or- Output Handler active object dequeues the next der of method invocation ± methods invoked asyn- message from its queue. It then sends the message chronously are executed based on a synchronization across the TCP connection to its destination. policy, not on the order of invocation. Simplifyconcurrent programming ± The message queue The operations on a shared object are relatively coarse- used by the Output Handler active objects allows grained ± in contrast, if operations are very ®ne- enqueue and dequeue operations to proceed con- grained the synchronization, data movement, and con- currently. These operations are subject to synchroniza- text switching overhead of active objects may be too tion constraints that (1) guarantee serialized access to a high [4]. 2 5 Structure and Participants Resource Representation (Output Handler Implementation) The structure of the Active Object pattern is illustrated in the following Booch class diagram: ± Represents the shared resource that is being mod- eled as an Active Object. The resource object typi- cally de®nes methods that are de®ned in the Client Interface. It may also contain other methods that loop { Client m = actQueue.remove() the Scheduler uses to compute run-time synchro- Interface dispatch (m) nization conditions that determine the scheduling } ResultHandle m1() order. ResultHandle m2() Scheduler ResultHandle m3() dispatch() Result Handle m1'() Activation m2'() 1 Queue ± When a method is invoked on the Client Interface, VISIBLE m3'() 1 insert() TO a Result Handle is returned to the caller. The remove() CLIENTS 1 Result Handle allows the method result value to 1 be obtained after the Scheduler ®nishes executing 1 n INVISIBLE the method. TO Resource Method CLIENTS Representation Objects 6 Collaborations The following ®gure illustrates the three phases of collabo- The key participants in the Active Object pattern include rations in the Active Object pattern: the following classes shown below: : Client : Activation : Represent- Client Interface (Output Handler Interface) client : Scheduler Interface Queue ation m1() ± The Client Interface is a Proxy that presents a INVOKE CREATE METHOD cons(m1') method interface to client applications. The invo- OBJECT RETURN RESULT future() cation of a method de®ned by the Client Interface CONSTRUCTION METHOD OBJECT HANDLE triggers the constructionand queueing of a Method / INSERT IN insert(m1') Object (see next bullet). PRIORITY QUEUE DEQUEUE NEXT remove(m1') METHOD OBJECT EXECUTION SCHEDULING Method Objects (Output Handler Operations) EXECUTE dispatch(m1') ± A Method Object is constructed for any method RETURN RESULT