Free lunches, mousetraps and the Actor model

A politician once mused

A free lunch is only found in mousetraps.

While this quote is amusing, it’s painfully true. In fact, the whole notion of a free lunch and its consequences was copacetically captured by Herb Sutter in an article entitled “The Free Lunch is Over: A Fundamental Turn Toward Concurrency in Software” that was published in Dr Dobb’s Journal back in 2005. In this well crafted masterpiece, Mr Sutter tore apart the misplaced belief that Moore’s Law would continue to unleash higher and higher CPU clock speeds and thus he predicted an end of the “free lunch” that we’ve had when it comes to increasing the performance of software applications. That is, clock speeds have roughly stabilized around 3GHz — and they’ve held there for a few years now.

As Mr. Sutter points out

the growth [in chip speeds speeds] will come mostly in directions that do not take most current applications along for their customary free ride.

Thus, obtaining an appreciable speed up in application performance requires taking advantage of multi-core chip architectures (where Moore’s Law has been realized). And to do this, of course, Mr. Sutter advocates concurrent programming:

applications will increasingly need to be concurrent if they want to fully exploit CPU throughput gains

Interestingly, the author concludes with a few points, one of which hits the nail on the head with respect to where the majority of mind share around this subject is focused:

we desperately need a higher-level programming model for concurrency than languages offer today

Indeed, the basic programming model of hip languages like Java is thread based. And while multi-threaded applications aren’t terribly hard to write — there are challenging to write correctly.

In a paper published in 2006 by Edward A. Lee entitled “The Problem with Threads“, the author argues that concurrent programming isn’t all that hard. In his view, the problem isn’t with concurrency — it’s with the prevailing model: threads.

As he states:

The problem is that we have chosen concurrent abstractions that do not even vaguely resemble the concurrency of the physical world

The author goes on to point out that the inherent non deterministic nature of threads presents a conundrum for developers:

a folk definition of insanity is to do the same thing over and over again and to expect the results to be different. By this definition, we in fact require that programmers of multithreaded systems be insane.

Mr. Lee provides an interesting story regarding the challenges and hidden dangers of concurrent programming. He relates an experience where a multi-threaded application that had a strict code review policy in place along with 100% code coverage (note, what type of coverage or how it was obtained wasn’t disclosed) ran for 4 years without error. Nevertheless, finally the code deadlocked. He goes on to speculate that many

multi-threaded general-purpose applications are, in fact, so full of concurrency bugs that as multi-core architectures become commonplace, these bugs will begin to show up as system failures

As such, Mr. Lee espouses an alternative to threads: actors. He’s quick to note that actor-oriented models aren’t new, but what he does suggest is interesting. He notes that languages that have actors, such as Erlang, weren’t taking root (at the time); thus, he submits:

We should not replace established languages. We should instead build on them.

Fast forward to today. Java the platform isn’t dead. It’s thriving with a multitude of alternate JVM languages — a few of which embed the actor model (namely Scala). What’s more, libraries written in Java and for Java are available, which enable the actor model (such as Kilim). Plus, the Java language itself has started to add more complex features to enable easier concurrent programming.

So what’s the lesson in all of this? First, the evolutionary instinct to throw more hardware at a performance problem is now extinct. Programs written today will need to be designed with concurrency in mind. Second, doing this with normal threads is challenging at best. A better, more understandable way is via the actor model, which is available in a number of frameworks and alternate languages. Therefore, learn them today, lest you find yourself snagged by a mousetrap, man.

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.