Combining Patterns for Architectural Solutions

The Active Object: A Pattern of Patterns

Let's revisit the Active Object pattern. Its primary goal is to decouple method invocation from method execution, allowing a client to make a non-blocking call while the work is performed asynchronously by a dedicated thread.

This pattern is a powerful abstraction, but it's not monolithic. It's actually a beautiful composition of several other, smaller patterns:

1. Proxy: The public interface the client interacts with is a Proxy. It has the same method signatures as the real object but doesn't perform the work. Its responsibility is to package the method call and its arguments into a message.
2. Command: The packaged message is a Command object. It encapsulates a request as an object. In modern C++, this is often implemented with a type-erased callable like std::function, which can wrap a lambda containing the method to call and its captured arguments.
3. Blocking Queue (Monitor Object): A thread-safe queue holds the Command objects. This queue acts as the communication channel between the client thread (the producer) and the Active Object's worker thread (the consumer). This component is a classic example of the Monitor Object pattern. The event loop we built in the last lesson implemented the consumer side of this.
4. Scheduler: A dedicated worker thread that continuously pulls Command objects from the queue and executes them. This is the "active" part of the pattern.
5. Servant: The underlying object that contains the actual business logic. The Scheduler invokes methods on the Servant.
6. Future (Optional): If a method call needs to return a value, the Proxy returns a std::future. The Scheduler, upon completing the task, uses a std::promise to set the result, which fulfills the future.

Case Study 1: Composing Command and Active Object with Type Erasure

The central challenge in implementing the Active Object pattern is handling the queue: how do you store different types of tasks (e.g., processInput(InputData) and processHangup(HangupData)) in the same queue?

The typical C++ solution is to use std::function<void()>. This works through a powerful technique called Type Erasure. You're not just using a library feature; you're leveraging a sophisticated composition of patterns under the hood.

To understand this composition, let's watch a segment from an excellent talk by Klaus Iglberger.

As the video explains, std::function isn't magic. It's a combination of:

• External Polymorphism: It imposes a polymorphic interface (the call operator ()) on types that were not designed with a common base class. It does this by creating its own internal, private class hierarchy.
• Bridge: It decouples the std::function interface from the implementation (the stored callable) using a pointer to an abstract base class (the "pimpl" idiom is a simple form of this).
• Prototype: It uses a virtual clone function to handle copying, allowing it to duplicate the wrapped callable object without knowing its concrete type.

This combination of patterns to solve the problem of type erasure is a perfect example of what it means to analyze pattern composition.

Now, let's see how we can apply this knowledge to build a more efficient Active Object. While std::function is convenient, its potential for heap allocation can be a performance bottleneck in high-throughput systems.

The TaskWrapper is a fantastic example for understanding how things work from first principles. It shows you that there's nothing magical about std::function—it's just a well-engineered application of fundamental design patterns, which you can replicate and customize yourself. The benchmark in the article (LINK, section 4) confirms the performance advantage of this approach by avoiding heap allocations.

Case Study 2: Architectural Composition with Half-Sync/Half-Async

We've seen how a single pattern, the Active Object, is composed of others. Now let's zoom out and see how the Active Object itself becomes a building block in a larger, system-level architecture. A classic example is the Half-Sync/Half-Async pattern.

The Half-Sync/Half-Async pattern is a brilliant solution for a common problem in concurrent servers: how do you get the high performance of asynchronous I/O without making all your business logic incredibly complex?

The pattern splits the system into three layers:

1. Asynchronous (or "Async") Layer: This layer interacts with external event sources. It's typically implemented with the Reactor pattern, which uses an event demultiplexer (like select, poll, or epoll on Linux) to handle many I/O sources in a single thread without blocking. Its job is to receive data efficiently and pass it on.

2. Queueing Layer: This is the communication channel between the async and sync layers. It's a set of thread-safe message queues.

3. Synchronous (or "Sync") Layer: This layer consists of multiple threads that perform the actual business logic. Each thread pulls a message from a queue and processes it synchronously (i.e., using simple, blocking code). This layer is often implemented as a pool of worker threads or, more elegantly, as a set of Active Objects.

Composing the Gateway

Let's see how these patterns compose in the gateway example from the slides:

• The Reactor (async layer) waits for data to arrive on any of the connected peer sockets.
• When data arrives for an InputChannel, the Reactor dispatches the event. The InputChannel's handle_input() method is called. This happens in the Reactor's thread.
• The InputChannel reads the data, consults a Router to determine the destination, and then puts the message into the message queue of the appropriate OutputChannel. This put operation is non-blocking and returns immediately.
• The OutputChannel is an Active Object (part of the sync layer). Its dedicated worker thread is sleeping, waiting for a message to appear in its queue.
• The put operation wakes the OutputChannel's worker thread. The thread dequeues the message and performs a synchronous, potentially blocking send() call to transmit the data to the final destination.

This architecture is powerful because it isolates concerns:

• The Reactor is concerned with I/O efficiency and responsiveness.
• The Active Object is concerned with executing a task (sending data) without blocking the main event loop.
• The composition of these two (via the queue) creates the Half-Sync/Half-Async pattern, giving you the best of both worlds: a highly responsive async front-end and a simple, easy-to-reason-about sync back-end.

Conclusion

Today we've seen that design patterns are not just isolated solutions but are fundamental building blocks for creating sophisticated software architectures. Understanding how to compose them is what elevates your designs from simple programs to robust, scalable, and maintainable systems.

Key Takeaways:

• Patterns are compositional: Complex patterns are often built from simpler ones. The Active Object pattern is a prime example, combining Proxy, Command, a Monitor Object (the queue), and a Scheduler.
• Implementation reveals composition: Diving into the "under the hood" implementation of features like std::function reveals their foundation in patterns like Type Erasure (which itself is a composition of External Polymorphism, Bridge, and Prototype).
• Architectural patterns emerge from composition: System-level patterns like Half-Sync/Half-Async are the result of combining tactical patterns like Reactor and Active Object to solve a larger problem—in this case, balancing I/O performance with programming simplicity.
• Intent matters: A key to successful composition is understanding the intent of each pattern. Knowing that the Reactor's intent is to demultiplex events and the Active Object's intent is to decouple invocation from execution helps you see why they fit together so well.

Next Lesson Preview:

This lesson concludes our module on concurrency and architectural patterns. You are now well-equipped to tackle the final portfolio project. In the first lesson of the next module, we will begin by defining a clean public API for our thread pool library and designing its internal architecture. We will draw directly on the patterns we've analyzed, especially the Monitor Object, Active Object, and the event loop logic, to lay the foundation for a professional-quality C++ component.