Implementations of all the patterns described below are freely available in the ACE and TAO open-source middleware. Complete information about these patterns is available in our various Pattern-Oriented Software Architecture (POSA) books. Earlier versions of some POSA patterns are available below, along with information about other DRE system patterns.
This paper describes the Reactor pattern, which supports the demultiplexing and dispatching of multiple event handlers that are initiated by the occurrence of synchronous events. This pattern simplifies event-driven applications by integrating the synchronous demultiplexing of events and the dispatching of their corresponding event handlers.
This paper describes the Asynchronous Completion Token pattern, which allows applications to efficiently associate state with the completion of asynchronous operations.
This paper describes the Proactor pattern, which supports the demultiplexing and dispatching of multiple event handlers, which are triggered by the completion of asynchronous events. The Proactor pattern simplifies asynchronous application development by integrating the demultiplexing of completion events and the dispatching of their corresponding event handlers.
Developing multi-threaded applications is hard since incorrect use of locks can cause subtle and pernicious errors. Likewise, developing multi-threaded reusable components is hard since it can be time-consuming to customize components to support new, more efficient locking strategies. This paper describes a pair of patterns, Strategized Locking and Thread-safe Decorator, and a C++ idiom, Scoped Locking, that help developers avoid common problems when programming multi-threaded components and applications.
This paper describes the Active Object pattern, which decouples method execution from method invocation and simplifies synchronized access to a shared resource by methods invoked in different threads of control.
The Monitor Object pattern synchronizes method execution to ensure only one method runs within an object at a time. It also allows an object's methods to cooperatively schedule their execution sequences.
This paper describes the Half-Sync/Half-Async pattern, which decouples synchronous I/O from asynchronous I/O in a system to simplify concurrent programming effort without degrading execution efficiency.
This paper describes the Thread-Specific Storage pattern, which allow multiple threads to use one logical access point to retrieve thread local data without incurring locking overhead for each access.
This paper describes the Double-Checked Locking pattern, which allows atomic initialization, regardless of initialization order, and eliminates subsequent locking overhead.
Creational patterns, such as Singleton and Factory Method, address object construction and initialization, but do not consider object destruction. In some applications, however, object destruction is as important as object construction. The Object Lifetime Manager pattern addresses issues associated with object destruction. Object Lifetime Manager is also an example of a complementary pattern, which completes or extends other patterns. In particular, the Object Lifetime Manager pattern completes creational patterns, such as Singleton, by considering the entire lifetime of objects.
This paper describes the Service Configurator pattern, which decouples the implementation of services from the time when they are configured. This pattern increases the flexibility and extensibility of applications by enabling their constituent services to be configured at any point in time. The Service Configurator pattern is widely used in application environments (e.g., to configure Java applets into WWW browsers), operating systems (e.g., to configure device drivers), and distributed systems (e.g., to configure standard Internet communication services). The examples in this paper illustrate the Service Configurator pattern using C++ and ACE. We have another paper that illustrates the Service Configurator pattern using Java applets.
This paper describes the Acceptor-Connector pattern. The intent of this pattern is to decouple (1) active and passive connection establishment and service initialization from (2) the processing the two endpoints of a service perform once they are connected and initialized. Common examples of communication services that utilize these patterns include Web browsers and Web servers, Object Request Brokers, and ``superservers'' that provide services like remote login and file transfer.
This paper describes the Wrapper Facade pattern. The intent of this pattern is to encapsulate low-level, stand-alone functions with object-oriented (OO) class interfaces. Common examples of the Wrapper Facade pattern are C++ wrappers for native OS C APIs, such as sockets or pthreads. Programming directly to these native OS C APIs makes networking applications verbose, non-robust, non-portable, and hard to maintain. This paper illustrate how the Wrapper Facade pattern can help to make these types of applications more concise, robust, portable, and maintainable.
This paper describes the Non-blocking Buffered I/O pattern, which decouples multiple sources of input from multiple sources of output to route data correctly without blocking a Gateway.
This paper describes the External Polymorphism pattern. This pattern allows classes that are not related by inheritance and/or have no virtual methods to be treated polymorphically.
Back to the Design Patterns home page.
Last modified 18:06:19 CST 25 January 2019