Monitor Object An Object Behavioral Pattern for Concurrent Programming Douglas C. Schmidt [email protected] Department of Computer Science Washington University, St. Louis 1Intent the corresponding consumer handler, whose thread then de- livers the message to its remote consumer. The Monitor Object pattern synchronizes method execution When suppliers and consumers reside on separate hosts, to ensure only one method runs within an object at a time. the Gateway uses the connection-oriented TCP [1] proto- It also allows an object’s methods to cooperatively schedule col to provide reliable message delivery and end-to-end flow their execution sequences. control. TCP’s flow control algorithm blocks fast senders when they produce messages more rapidly than slower re- ceivers can process the messages. The entire Gateway should 2 Also Known As not block, however, while waiting for flow control to abate on outgoing TCP connections. To minimize blocking, there- Thread-safe Passive Object fore, each consumer handler can contain a thread-safe mes- sage queue that buffers new routing messages it receives from its supplier handler threads. 3 Example One way to implement a thread-safe Message Queue is to use the Active Object pattern [2], which decouples the Consider the design of the communication Gateway shown thread used to invoke a method from the thread used to exe- in Figure 1. The Gateway process contains multiple supplier cute the method. As shown in Figure 2, each message queue active object contains a bounded buffer and its own thread of control that maintains a queue of pending messages. Using Supplier Routing Consumer Handler Table Handler Consumer 2: find (msg) 3: put (msg) 1: put (msg) Handler Supplier 2: put (msg) Consumer Handler Message Queue Handler 4: get (msg) 5: send (msg) Supplier 1: recv (msg) Handler 3: get (msg) INCOMING OUTGOING 4: send (msg) INCOMING GATEWAY MESSAGES OUTGOING MESSAGES MESSAGES MESSAGES GATEWAY OUTGOING MESSAGES Figure 2: Implementing Message Queues as Active Objects SUPPLIER CONSUMER SUPPLIER CONSUMER Figure 1: Communication Gateway the Active Object pattern to implement a thread-safe mes- sage queue decouples supplier handler threads in the Gate- handler and consumer handler objects that run in separate way process from consumer handler threads so all threads threads and route messages from one or more remote sup- can run concurrently and block independently when flow pliers to one or more remote consumers, respectively. When control occurs on various TCP connections. a supplier handler thread receives a message from a remote Although the Active Object pattern can be used to imple- supplier, it uses an address field in the message to determine ment a functional Gateway, it has the following drawbacks: 1 Performance overhead: The Active Object pattern pro- 3. Objects should be able to schedule their methods coop- vides a powerful concurrency model. It not only synchro- eratively: If an object’s methods must block during their nizes concurrent method requests on an object, but also can execution, they should be able to voluntarily relinquish their perform sophisticated scheduling decisions to determine the thread of control so that methods called from other client order in which requests execute. These features incur non- threads can access the object. This property helps prevent trivial amounts of context switching, synchronization, dy- deadlock and makes it possible to leverage the concurrency namic memory management, and data movement overhead, available on hardware/software platforms. however, when scheduling and executing method requests. Programming overhead: The Active Object pattern re- quires programmers to implement up to six components: 6 Solution proxies, method requests,anactivation queue,ascheduler,a For each object accessed concurrently by client threads de- servant,andfutures for each proxy method. Although some fine it as a monitor object. Clients can access the services components, such as activation queues and method requests, defined by a monitor object only through its synchronized can be reused, programmers may have to reimplement or sig- methods. To prevent race conditions involving monitor ob- nificantly customize these components each time they apply ject state, only one synchronized method at a time can run the pattern. within a monitor object. Each monitored object contains a In general, the performance and programming overhead monitor lock that synchronized methods use to serialize their outlined above can be unnecessarily expensive if an applica- access to an object’s behavior and state. In addition, syn- tion does not require all the Active Object pattern features, chronized methods can determine the circumstances under particularly its sophisticated scheduling support. Yet, pro- which they suspend and resume their execution based on one grammers of concurrent applications must ensure that certain or more monitor conditions associated with a monitor object. method requests on objects are synchronized and/or sched- uled appropriately. 7 Structure 4 Context There are four participants in the Monitor Object pattern: Applications where multiple threads of control access ob- Monitor object jects simultaneously. A monitor object exports one or more methods to clients. To protect the internal state of the monitor 5Problem object from uncontrolled changes or race conditions, all clients must access the monitor object only through Many applications contain objects that are accessed concur- these methods. Each method executes in the thread of rently by multiple client threads. For concurrent applications the client that invokes it because a monitor object does to execute correctly, therefore, it is often necessary to syn- not have its own thread of control.1 chronize and schedule access to these objects. In the pres- For instance, the consumer handler’s message queue in ence of this problem, the following three requirements must the Gateway application can be implemented as a mon- be satisfied: itor object. 1. Synchronization boundaries should correspond to object methods: Object-oriented programmers are accus- Synchronized methods tomed to accessing an object only through its interface meth- ods in order to protect an object’s data from uncontrolled Synchronized methods implement the thread-safe ser- changes. It is relatively straightforward to extend this object- vices exported by a monitor object. To prevent race oriented programming model to protect an object’s data from conditions, only one synchronized method can execute uncontrolled concurrent changes, known as race conditions. within a monitor at any point in time, regardless of the Therefore, an object’s method interface should define its syn- number of threads that invoke the object’s synchronized chronization boundaries. methods concurrently or the number of synchronized methods in the object’s class. 2. Objects, not clients, should be responsible for their own method synchronization: Concurrent applications For instance, the put and get operations on the con- are harder to program if clients must explicitly acquire sumer handler’s message queue should be synchronized and release low-level synchronization mechanisms, such as methods to ensure that routing messages can be inserted semaphores, mutexes, or condition variables. Thus, objects and removed simultaneously by multiple threads with- should be responsible for ensuring that any of their methods out corrupting a queue’s internal state. requiring synchronization are serialized transparently, i.e., 1 In contrast, an active object [2] does have its own thread of control. without explicit client intervention. 2 Monitor lock 1. Synchronized method invocation and serialization: When a client invokes a synchronized method on a moni- Each monitor object contains its own monitor lock. tor object, the method must first acquire its monitor lock. A Synchronized methods use this monitor lock to seri- monitor lock cannot be acquired as long as another synchro- alize method invocations on a per-object basis. Each nized method is executing within the monitor object. In this synchronized method must acquire/release the monitor case, the client thread will block until it acquires the monitor lock when the method enters/exits the object, respec- lock, at which point the synchronized method will acquire tively. This protocol ensures the monitor lock is held the lock, enter its critical section, and perform the service whenever a method performs operations that access or implemented by the method. Once the synchronized method modify its object’s state. has finished executing, the monitor lock must be released so For instance, a Thread Mutex [3]couldbeusedto that other synchronized methods can access the monitor ob- implement the message queue’s monitor lock. ject. Monitor condition 2. Synchronized method thread suspension: If a syn- chronized method must block or cannot otherwise make im- Multiple synchronized methods running in separate mediate progress, it can wait on one of its monitor condi- threads can cooperatively schedule their execution se- tions, which causes it to “leave” the monitor object temporar- quences by waiting for and notifying each other via ily [5]. When a synchronized method leaves the monitor monitor conditions associated with their monitor object. object, the monitor lock is released automatically and the Synchronized methods use monitor conditions to deter- client’s thread of control is suspended on the monitor con- mine the circumstances under which they