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.
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.
Actors, in the sense of modeling actions, with messages, etc is a way of modeling software that provides a couple of useful items...
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.
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.
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.
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.
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.