Readers are assumed to have at least a passing familiarity with an object-oriented language and an actor-oriented language (e.g. Erlang, Pony). Note that objects and actors are orthogonal abstractions and therefore a language may implement both – Pony is an example. Language abstractions orthogonal to both objects and actors will not be considered here, e.g. static vs. dynamic typing. Because Pony mixes objects and actors, this paper will use Erlang as the prototype for actors in order to draw a sharper contrast between objects and actors. Further exposition of Pony will require its own paper. Fundamentally, software is logic interacting with state. Logic is encapsulated in functions (aka methods) and state is visible to one or more functions. When state is visible to multiple simultaneously active functions, and one or more of those functions can write that state (aka shared mutable state), accesses must be coordinated in order to guarantee consistent behavior. Both objects and actors are encapsulation abstractions which define a boundary around logic and state. Figure 1 depicts the structure of a typical object and a typical actor. An object encapsulates one or more public methods, zero or more private methods, and internal state. Each method encapsulates logic and local state. All methods may call each other and the public methods of other objects to which they have a reference. The internal state is visible to all methods, e.g. instance variables. An actor encapsulates one or more functions and a message queue. Each function encapsulates logic and local state and all functions may call each other. All functions may receive messages from the queue and send messages to other actors. For a given problem domain, the logic and state in an object implementation and an actor implementation will be substantially the same – modulo the abstractions made available by the language. The most salient differences between objects and actors are the entry points across their encapsulation boundary and the sharing of state within this boundary. As depicted in Figure 1, every public method of an object is an entry point; actors have only a single entry point in the form of a message queue. Within an object there is mutable state visible to multiple functions – thus each individual object is potentially an instance of the shared mutable state problem in microcosm. Within an actor there is no mutable state visible to multiple functions – the message queue is visible to multiple functions but it is read only. Given that public methods of an object can be called at any time in any order by any external method with a reference to that object, these public methods can be simultaneously active even within a single thread. Therefore the object’s internal state can change while a method is executing even if that method did not change said state. A simple example of this scenario is depicted in Figure 2. In general, the shared mutable state problem may occur when two or more instances of methods within the same object are simultaneously live, i.e. have frames on the stack. Note that these could be instances of the same method. In order to guarantee this behavior does not occur, access coordination logic will need to be implemented around the internal state of the object even for single threaded implementations, e.g. locking. This definition encompasses recursion but in that situation state modifications are contained within the same function and are immediately apparent to the developer. Messages can be sent to an actor at any time in any order [1] by any actor with a reference to that actor. Messages are processed serially by any function within the actor; logic within the function determines the point at which messages are processed and which specific message in the queue to process. Because messages are processed serially, the corresponding logic is executed serially. Thus the actor model does not exhibit the shared mutable state problem inherent in the object model. Even if an object were to be designed to have only a single public method to mimic the single entry point of actors, that public method can still be called at any time in any order by any external method with a reference to that object and therefore the shared mutable state problem is still present. For objects, methods external to the object determine when, and in what order, logic within that object is activated. For actors, logic internal to the actor itself determines when it will be activated (by extracting a message from the queue). Thus, fully comprehending the behavior of an object requires developers to look beyond the object itself – potentially far beyond. Fully comprehending the behavior of an actor requires inspection of only the functions within that actor. Given that logic within the actor decides when to process the next message and which message to process, it would be simple to implement logic to guarantee that invariants are maintained before each message is processed. Implementing a similar guarantee for objects is more complicated. Because the actor model does not exhibit the shared mutable state problem, an actor implementation that executes correctly in a serial scenario will execute correctly in a concurrent scenario without modification. The same cannot be said for an object implementation. To gain experience with the actor model, I suggest starting with a language for which the actor model is intrinsic. The actor language with the largest ecosystem and market footprint is Erlang. Erlang programs are compiled to a virtual machine that schedules actors. Pony is a promising new actor language that blends actors, objects, and capabilities. Pony is a compiled language and an actor scheduler is linked into the binaries. When transitioning from an object model with threaded concurrency to an actor model with message passing concurrency, developers will need to make a mental realignment. Actor creation is almost as fast as a function call and this changes the optimal approach to scaling. Imagine a system that processes messages requiring a sequence of steps. Rather than having permanently running actors for each step where each actor serially executes a step in the message processing sequence, a better approach is to spawn a set of transient actors for each message when it arrives. The bottom line: When compared to the actor model, the object model is more brittle, its encapsulation more permeable, and its cognitive load on developers higher. To summarize, the advantages of actors relative to objects are: No shared mutable state problem in serial or concurrent scenarios Zero modification needed to go from serial to concurrent scenarios Easier implementation of invariant enforcement between logic activations Lower cognitive load on the developer [1] Erlang and Pony guarantee that messages sent by actor A to actor B appear in B’s message queue in the order A sent them.

Too Long; Didn't Read

Get free API security automated scan in minutes

Objects vs. Actors

Too Long; Didn't Read

@jmills

RELATED STORIES