Asynchronous Message Passing With Actors in Objective-C
Actors, these strangers
Although we are all in love with Objective-C, the power of a language itself is given by its inner features. Languages like Ada have a built-in concurrency model, while Objective-C needs external libraries (let’s say
libdispatch) to try to achieve the same power of expression found in richer languages.
The same happened for the implementation of the Actor Model. The standout language for the feature of asynchronous message passing using the actor model is Erlang. From Wikipedia:
The actor model in computer science is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent digital computation: in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received.
That said, languages like Ada and Erlang are semantically more powerful than Objective-C, as some features are expressed at the language level rather than through libraries provided in the user space.
Adopting the Actor Model means avoiding the Object Orientation orthodoxy and forcing the developer to write software as a collection of smaller communicating programs that do not share state. Software written using the Actor Model approach is inevitably more “pure” than its traditional counterpart as the paradigm expresses a better level of abstraction, no matter which language is used.
In the Actor Model concurrency paradigm, each Actor waits to receive a message. When it gets one it processes the message, and notifies – via another message – one or more other actors. Actors communicate asynchronously by message passing, rather than sharing resources or using primitive mechanisms (locks, semaphores, etc…) to guarantee mutual access to them. As is well known, the standard approach carries a high risk of race conditions, deadlocks and similar pesky problems. In their pure form, Actors can scale to thousands of threads spread out over hundreds of cores.
Thread safety, the standard path
Returning to the world of Objective-C from this little digression, a widely accepted way to deal with a locking mechanism is to use queues that provide an intrinsic way to stem the danger of thread safety. Grand Central Dispatch (GCD) should be the first choice that comes to mind, but it does not solve the thread safety issues – and the programmer still has to design carefully to guarantee the thread safety.
The following code provides an intrinsic lock mechanism for a mutable data structure using a serial queue.
1 2 3 4 5 6 7
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
In the given class there are no explicit locks or similar primitives to guarantee mutual access, but still, any method will need to ensure that the data is accessed under mutual exclusion. This becomes particularly problematic when the class is modified at a later date and the real thread safety of the class is hard to prove.
Consider a class whose responsibility is to persist data on a SQLite database, which is an example of shared data. Let’s consider the threading issues dealing with different Managed Object Contexts in Core Data: one could try to solve the problem with an Actor (a thread) that intrinsically applies a lock mechanism to the shared data and thread safety.
The actor semantics are learnable by most developers and ‘safer’ than their locked counterparts. They raise the abstraction level and allow developers to focus on coordinating access to the data rather than protecting all accesses to it with locks.
Actors, talking business
We are about to propose an Actor Model implementation inspired on the original implementation of Valletta Ventures library.
The main classes are Messages and Actors. Let’s start with the Message: it is simply a wrapper for a selector.
1 2 3 4 5 6 7
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
The intention is to subclass
Message to add custom fields appropriate to the message. It is important to note that in order to avoid sharing state,
Message and any of its subclasses must be copied.
Actor class looks as follows:
1 2 3 4 5 6 7
with the following implementation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58
The important parts here are:
- Each Actor is a
- Actors are meant to be subclassed to perform ad-hoc tasks
executeMessage:can be called from any thread, and this guarantees the thread safety
An Actor, when booted, will start an NSRunLoop which will be used to dispatch any queued messages to the correct method. Using the NSRunLoop we will idle for free when no messages are queued.
executeMessage: is used to pass a message to an Actor, which copies the message to avoid shared state and places the call in the run loop. When called by the run loop the
_processMessage: selector calls the selector specified in the message with the message as an argument. The message is automatically released after the method has returned.
Let me play, please
The easiest way to see this in action is with a super simple example (taken from the original implementation of Valletta Ventures library. First, subclass Actor:
1 2 3 4 5 6 7
1 2 3 4 5 6 7 8 9
then create some actors, put them in a chain and fire the message passing:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
These actor will keep passing the message between them for 10 seconds, after which the actors will be cancelled.
The full code can be found on GitHub in my ADBActors repository
Uh, cool stuff, so…
You could consider to use the actor paradigm when:
- you can decompose your problem into a set of independent tasks linked by a clear workflow
- you want to be able to cancel jobs
- you want to scale across threads and cores
- you have a complex system that involves dependencies and shared state
- you want to avoid the usage of explicit locks to protect shared state and actually make copies of that state (messages) and reacting to them locally
- you want to code components that are intrinsically thread safe