No matter what programming language you use to create “the next big thing™”, when it comes to running your code, there will – eventually – be a thread) that has to execute and compute the result of your program. You may be wondering why you should even care about this threading lark?
Well, modern computing hardware is typically not sporting faster clock speeds, but instead features multiple cores, or physical processors. If you have a single threaded program, then you cannot make use of the abundant power that modern hardware makes available; surplus cores simply sit idle and unused. For desktop computers this is less of an issue, but for server based applications, having wasted resources that you already paid for is quite an issue.
A common scenario that you are likely familiar with – either implicitly or explicitly – is for your program to run on a single thread. In this situation the program executes imperatively. For readers familiar with C or a scripting language like PHP or Ruby, this generally means the code runs top to bottom. Consider this trivial example:
// create a variable
var foo = 0
// loop and increment the var with each iteration
def doSomething =
for(i <- 1 to 10){
foo += 1
}
// check the value of foo
foo This kind of code, irrespective of the exact syntax, should be familiar to anyone who’s ever used a mainstream programming language. When this program is run with a single thread, the result will, as one might expect, be an integer value of 10. Seemingly straightforward.
Now, reconsider what would happen if you ran this same program on two concurrently executing threads that shared the same memory space. If you’ve never done any multi-threaded programming, the answer to this question may not be obvious: as each thread runs its own counting loop, both thread A and thread B will be setting the value of the foovariable. This will have some wacky side-effects in that one thread will constantly be pulling the rug out from under the others feet. This is not constructive for either thread.
This rather unfortunate scenario has several “solutions” that are found in the majority of mainstream programming languages: one of these solutions is known as synchronisation). As you might have guessed from the name, the two concurrently executing threads are synchronised so that only one thread updates the foo variable at a time. In various programming languages, locks) are often used as a synchronisation mechanism (along with derivatives like Semaphoresand Reentrant Locks). Whilst this article isn’t long enough to go into the details of all these things (and its a deep subject!), the general concept is that when a thread needs a shared resource, it locks it for its exclusive use whilst it does its business. For all the while thread A is locking, thread B (or indeed, thread n) is “blocked”, that is to say thread B is waiting on thread A and cannot do any work during that time. This gets awkward. Quickly.
Hopefully this gives you a high-level appreciation for the issues associated in writing concurrent software. Even in a small application, concurrent operations could quickly become a practical nightmare (and often do), let alone in a large-scale distributed application that has both inter-process and inter-machine concurrency concerns. Writing software that makes effective and correct use of these traditional concurrency tools is very, very tricky.
Time for a re-think.
As it turns out, some clever folks realised back in the mid-sixties that manual threading and locking was a poor level of abstraction for writing concurrent software, and with that, invented the actor model. Actors essentially allow the developer to reason about concurrent operations without the need for explicit locking or thread management. In fact, Actors were largely popularised by the Erlang programming language in the mid-eighties, where Erlang actors allowed telecoms companies such as Ericsson to build highly fault-tolerant, concurrent systems, that achieve extreme levels of availability – famously achieving “nine nines”: 99.9999999% annual uptime. In fact, Erlang is still highly popular in the TelCo sector even today, and many of your phone calls, SMS and Facebook chat IMs all use Erlang actors as they wind their way across the interweb.
So what is the actor model? Well, primarily actors are a mechanism for encapsulating both state and behaviour into a single, consolidated item. Each actor within an application can only see its own state, and the only way to communicate with other actors is to send immutable “messages”. Unlike the earlier example in the introduction that involved shared state (the foo variable), and resulted in blocking synchronisation between threads, actors are inherently non-blocking. They are free to send messages to other actors asynchronously and continue working on something else – each actor is entirely independent.
In terms of the underlying actor implementation, actors have what is known as a “mailbox”. In the same way that a postman places letters through a physical mailbox, those letters collect on top of each other one by one, with the oldest letter received being at the bottom of the pile. Actors operate a similar mechanism: when an actor instance receives a message in its mailbox, if it’s not doing anything else it will action the message, but if it’s currently busy, the message just sits there until the actor gets to it. Likewise, if an actor has no messages in its mailbox, it will consume a very small amount of system resources, and won’t block any applications threads: these qualities make actors a much easier abstraction to deal with and lend themselves to writing concurrent (and often distributed) software.
Actors by example
Enough chatter, let’s look at an example of using actors. The samples below make use of a toolkit called Akka, which is an actor and concurrency toolkit for both Scala, and the wider polyglot JVM ecosystem. I’ll be using Scala here, which is a hybrid-functional programming language. In short that means that values are immutable, and applications are typically constructed from small building blocks (functions). Scala also sports a range of language features that allow for concise, accurate programming not available in other languages. However, the principles of these samples can be easily replicated both in imperative languages like C# or Java, and also in languages such as Erlang.
The most basic actor implementation one could make with Akka would look like this:
import akka.actor._
class MyActor extends Actor {
def receive = {
case i: Int => println("received an integer!")
case _ => println("received unknown message")
}
}This receive method (technically a partial function) defines the actors behaviour. That is to say, the actions the actor will take upon receipt of different messages. With the receiving behaviour defined, lets send this actor a message:
import akka.actor._
// boot the actor system
val system = ActorSystem("MySystem")
val sample = system.actorOf(Props[MyActor])
// send the actor message asynchronously
sample ! 1234
Besides the bootstrapping, the ! method (called “bang”) is used to indicate a fire and forget (async) message send tosample actor instance, which, as you saw from the earlier code listing will output a message to the console. Clearly there are more interesting things to do than print messages to the console window, but you get the idea. At no point did the developer have to specify any concrete details about threading, locking or other finite details. Akka allows you fine control over thread allocation if you want it, but relatively default settings will see you through to about 20 million messages a second, with Akka being able to reach 50 million messages a second with some light configuration. This is staggering performance for a single commodity server. With all that being said, this example is of course very trivial, so lets talk about what else actors (and Akka) can do…
It turns out that the conceptual model of actors is a very convenient fit for a range of problems commonly found in business, and Akka ships with a range of tools that make solving these problems in a robust, and correct way nice and simple. Whilst this blog post is too short to talk about all of Akka’s features, one that is no doubt of interest to most readers is fault tolerance.
Supervisor Hierarchies
Think about the way many people write programs: how many times have you written a call to an external system, or to the database, and just assumed that it would work? Such practices are widespread, and Akka is entirely based around the opposite idea: failure is embraced, and assumed to happen. With this frame of reference one can design systems that can recover from general faults gracefully, rather than having no sensible provision for error. One of the main strategies for providing such functionality is something known as Supervisor Hierarchies. As the name suggests, actors can be “supervised” by another actor that takes action in the case of failure. There are a couple of different strategies in Akka that facilitate this structure:
- All for one: If the supervisor is monitoring several actors, all of those actors under the supervisor are restarted in the event that one has a failure.
- One for one: If the supervisor is monitoring multiple actors, when one actor has a failure, it will be restarted in isolation, and the other actors will be unawares that the failure occurred.
Simple enough. Let’s see supervision in action:
import akka.actor.Actor
class Example extends Actor {
import akka.actor.OneForOneStrategy
import akka.actor.SupervisorStrategy._
import akka.util.duration._
override val supervisorStrategy = OneForOneStrategy(
maxNrOfRetries = 10, withinTimeRange = 1 minute){
case _: NullPointerException => Resume
case _: Exception => Restart
}
def receive = {
case msg => ....
}
}
You can see from the listing that the structure of the actor is exactly the same as the trivial example earlier – its just augmented with a customisation of the supervisionStratagy. This customisation allows you to specify different behaviour upon different errors arising. This is exceedingly convenient, and very easy to implement.
Conclusion
The actor model is a simple abstraction that facilities easier development of robust, concurrent software. This article only scratches the surface of what’s available, but there is a lot of cutting edge work being done right now in the area of concurrency and distributed systems. If this article has piqued your interest, there has never been a better time to get your hands dirty and try something new!
