Menu
Well, the title's pretty much it: if I sat a non-techie/my mum/twelve-year old boy/cocker spaniel in front of you and asked you to explain actors to them, where would you start? I ask because my master's project involves them to a pretty large degree, and every other day someone asks me to tell them what I'm doing. When I'm talking to other people on my course it's not so bad—usually the concept is foreign but understandable—but recently my flatmate, a chemist, asked me to explain it to her, and to say I struggled would be a pretty humongous understatement.
I'm looking for some sort of explanation that conveys the idea, rather than the technical underpinnings. It can be a metaphor, and it doesn't have to be precise—I just want to make them understand what I'm doing with them. Any ideas?
837
An actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other actors; create a finite number of new actors; designate the behavior to be used for the next message it receives.
The actor model abstraction allows you to think about your code in terms of communication, not unlike the exchanges that occur between people in a large organization. Use of actors allows us to: Enforce encapsulation without resorting to locks.
The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Actor model is inherently concurrent.
Erlang actor functions often follow this idiom of matching an incoming message, then making a tail-recursive call back to the same function. State can be maintained in the actor by passing it in a function parameter and modifying it on the recursive call. The {stop} message is a special message to stop the process.
There can be many actors. All actors act "at the same time". The concurrency is a key part of this model.
Actors cannot know what other Actors are thinking. The only way to move information is with a message. (no shared state)
Actors can receive messages, and act on them by:
doing computation with the data in them
sending messages to other actors
creating other actors.
ignoring/discarding the message.
This basically makes actors just like... People. People don't know what each other are thinking, they must send messages to convey information, they have the choice of ignoring incoming messages, considering them, or communicating with other people. Random bad things can happen to people. Lots of people all do things at the same time. To handle more load, add more people.
Regarding your masters project, I suggest finding out about the Erlang Web framework. The programming language Erlang is based on the Actor model, and is used to great effect in scalable systems including phone switches... and the Facebook messaging system.
59
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
