19

I have read a bit about the actor model, but don't really understand how to use actors in a real world situation – how to model a problem with them.

Can someone please explain? A simple example or links to examples would be much appreciated.

Pnutus
  • 299
  • 1
  • 2
  • 5
  • Or do you mean the [actor model](http://en.wikipedia.org/wiki/Actor_model)? – back2dos Aug 08 '11 at 20:24
  • I suspect you mean Agents, not Actors. If so, check out this wikipedia entry: http://en.wikipedia.org/wiki/Software_agent – DwB Aug 08 '11 at 20:32
  • 1
    They star in Green Lantern and Planet of the Apes in order to entertain the geeks at /. In turn, the geeks at /. entertain the rest of us. – Job Aug 09 '11 at 02:30
  • I do mean the actor model, and have updated my post to clarify. – Pnutus Aug 09 '11 at 09:55

3 Answers3

21

Actors, in the sense of modeling actions, with messages, etc is a way of modeling software that provides a couple of useful items...

  1. Actors can live on a single thread, allowing non-thread-safe/non-concurrent operations to happen without a bunch of locking magic. An actor will respond to messages in its inbox. When you want it to process a command you send it a message and it will take care of them in the order they are received. Just like a normal queue. Thread safe is killer here, and I use this in a number of open source projects I work on.

  2. In some languages, Scala for example, it's easy to turn actor based code in a single process into a distributed system by breaking apart the actors and turning the channels they communicate over into remote channels. This changes between implementations on how easy it is, but it's an awesome feature.

  3. Helps focus on Task Based events rather than CRUD events. CRUD is simple but it's just like interacting with a filing cabinet. If we can provide more value than that in the software we produce, why are we doing it? Tying multiple actions to a single "Update" command in a task based system is more useful than just saving to the DB. This also gets into stuff like CQRS.

Matt Thomas
  • 173
  • 6
Travis
  • 1,329
  • 6
  • 14
  • Thank you for your helpful answer and links. What language would you recommend starting looking at to get a better feel for actors? – Pnutus Aug 09 '11 at 10:00
  • 1
    I think it depends on what languages you are comfortable with. Scala might have some of the best documentation around actors though, since they are a language concept. Erlang is awesome for messaging in general though, the whole language is based around that concept. – Travis Aug 09 '11 at 20:30
  • I'll take a look at Scala and Erlang. Found [this](http://learnyousomeerlang.com/) beginner's guide for Erlang, gonna start there. Thanks! – Pnutus Aug 09 '11 at 21:17
  • +1: Very interesting. Do you know if there is any C++ library that implements remote actors? I would be glad to use Scala but my project is in C++. – Giorgio May 01 '12 at 09:11
  • I'm not aware of any remote actor libraries for C++. You could look at messaging frameworks or the use of sockets for interprocess communication. It's non-trivial to implement. – Travis Jun 05 '12 at 17:27
  • 1
    Consider this C++ Actor Model implementation: http://www.actor-framework.org/ – Chen OT Dec 11 '15 at 17:46
4

Travis's answer is solid. When you start talking about concurrency, you are trying to solve resource problems. Concurrency with threads and locks are pretty easy to do wrong. The actor model helps to force you to program concurrent portions of your code as self contained nuggets that can be performed in parallel and without depending on another piece of code. You are trying to avoid nastiness like race conditions and deadlocks.

Actors are like you and I in this conversation. You just can't reach into my brain and pick out what I'm typing. You passed me a message saying "Why do we exist?" I sat and crunched some numbers and sent a reply "I think, therefore I am." You couldn't tell what I was doing on my own slice of planet Earth the only contact you have with me is through the messages we pass back and forth.

EDIT:

You didn't say which languages you are comfortable in, but see if there is an actor implementation in your language. Maybe the simplest would be some of the actor libs in python. But probably better for learning would be Erlang. The language is a little rough but once you get over the nuances, it's a good language.

M15K
  • 203
  • 1
  • 6
  • I'm not certain if gnat's edit is directed towards me, but my weapon of choice usually tends to be Haskell. Erlang is definitely a good language. Haskell has traditionally relied on CSPs for concurrency but there are some actor implementations out there. – M15K Dec 06 '13 at 17:20
-2

Actors are an element of use case diagrams that represent any external entity (user, external system, etc.) that can act on a system. Any basic use case will contain actors--just google "use case" for a wealth of examples.

afeygin
  • 738
  • 1
  • 4
  • 9