Friday, January 23, 2015

Revisiting the Active Object Pattern - with C++11 Closures

I have a confession: with the never ending things going on (you know: life ;-) I missed the (fairly) recent changes in the C++ language.  C++ was my first OO language and it probably remains my favorite.  I can't help but love the mix of high level abstractions with metal grinding pointer arithmetic - it's like a cool sports car with manual transmission. Beauty and power.  You have to be more alert, more involved. That's part of the fun - you are taking control.  But for some time now C++ felt old, tired, disconnected from the endless stream of new languages.  Until C++11 came along.  

C++11  (formerly known as C++0x) is the most recent version of the standard of the C++ programming language. It was approved by ISO on 12 August 2011. C++11 includes several additions to the core language and extends the C++ standard library, incorporating most of the C++ Technical Report 1 (TR1) libraries.
Bjarne Stroustrup wrote that:
Surprisingly, C++11 feels like a new language: The pieces just fit together better than they used to and I find a higher-level style of programming more natural than before and as efficient as ever.
And it does feel like a new language. And this is exciting for geeks like me.  In this blog post I discuss how I implemented Schmidt's Active Object pattern in a novel way using C++11 Closures.

First, another confession: for a long time I've suffered from Node envy.  Node.js envy, to be precise. Look at this "Hello World" Javascript code:



What I "envy" is not the use of asynchronous I/O operation with callbacks ("the callback pattern"), but the compelling beauty of Lambda functions.  Lambda functions simplify asynchronous programming because they allow us to write code that is seemingly synchronous.  The code that is executed by the lambda function is temporally disjointed from the code that precedes it, and yet both parts are spatially co-located.  And the outcome is smaller, tighter code that feels more natural and is easier to read and maintain.  And this can be done in C++11.

I won't discuss C++11 lambda functions because others have done this better than I can.  This article is an example of some of the great coverage you can find on the net (Alex Allain has lots of interesting material to read).  But I do want to touch on the difference between Lambda functions and Closures, since my implementation below uses Closures.  Lambda functions are anonymous functions that don't need to be bound to a name and can be specified as lambda expressions.  A Closure is an example of a lambda function which "closes" over the environment in which it was specified (meaning that it can access the variables available in the referencing environment).  Alex Allain's article (which I referenced above) doesn't make a big distinction between lambdas and closures and simply treats closures as lambdas with "variable capture".  Syntactically in C++ lambdas and closures are almost identical, so the distinction is there and it is slight, yet I think it is important to note the semantic difference.

On to Active Object.

Douglas Schmidt describes the Active Object design pattern in Pattern Oriented Software Architecture (Volume 2: Patterns for Concurrent and Networked Objects):
The Active Object design pattern decouples method execution from method invocation to enhance concurrency and simplify synchronized access to objects that reside in their own threads of control. 
Once again, I don't want to paraphrase the work of others, so I assume that you are knowledgeable about the details of the Active Object pattern.  If not, you should probably familiarize yourself with the pattern before reading on.
To illustrate my ideas, I will only concentrate on one variation of the Active Object  pattern.  In this variation the Client and Proxy are "folded" into the same object and the Scheduler and ActivationList implement a simple message queue policy (this is reminiscent of Schmidt's original AO paper, which he later expanded on).  I think this is probably the most prevalent variation of the pattern - in which we want to serialize access to an object, and use an in-order queue (FIFO) to "bounce" the method invocation from one thread to another.
Let's look at the example code from the Wikipedia entry on Active Object.  The Wikipedia code is implemented in Java and I went and implemented it using C++11.  I placed the comments in the code to explain the logic.

The more "traditional" method of implementing ActiveObject in C++ involves defining two sets of interfaces: a public interface and a private interface.  Every method in the public interface also appears in the private interface.  The public interface is used by clients to invoke methods on the object, and they create a message indicating the request and its parameters and enqueue the message. The private interface is used by the dispatcher which dequeues messages and invokes the private method.  This works well enough but creates big classes that have a lot of extraneous code that is there just to get all this mechanics to work.  Every change to the interface requires a series of changes (public and private interface; message definition).

A somewhat more sophisticated implementation uses functors.  We no longer need the code which does the switching on the message type when we grab a message from the FIFO and dispatch it.  But the sophistication of the code probably only adds a layer of obfuscation if you are not familiar with the underlying idiom.   We gain too little from this to be worthwhile.

Now let's come full circle and return to the Closure implementation of ActiveObject and add a few of features to it.

No comments:

Post a Comment