I worked on a hierarchical, distributed control system written in Erlang, and I found the actor model well suited to that problem domain.
We had to control various devices based on sensor data, but we also needed to make sure that the workload was distributed across the devices in an efficient way. To implement that, we had one actor per device that was solely responsible for adjusting the device output based on sensor data. Then we had another actor that was responsible for looking at the behavior of a cluster of devices and distributing the load between them. This "load distribution" actor wouldn't control the devices directly, but instead would send adjustments to the actors directly controlling the device.
I find it very natural to anthropomorphize actors. That is, if you were to think about how you would organize a group of people to do the work of the system (in a very Taylorist sort of way) the roles of those people map neatly onto the actors one would create.
One common pattern is the manager/supervisor/worker pattern[0]. I see this as mapping fairly neatly onto the project manager/people manager/employee structure that you see in many organizations.
I think what most people want to know is whether they could re-write a multi-threaded program that is currently using synchronization primitives (locks, semaphores, mutexes, etc) with actors.
Like, show me the producer-consumer pattern using actors.
There are many more examples out there. Anything that a multi-threaded program can do, an actor can do..
I just think that actors are inherently more complex than threads for simple problems. For complex problems, I think actor are probably a better choice.
A good example of a simple program is managing multiple TCP connections. At least in my (somewhat limited) experience with actors, polling TCP file descriptors is easier to manage creating an actor for each one.
> I think what most people want to know is whether they could re-write a multi-threaded program that is currently using synchronization primitives (locks, semaphores, mutexes, etc) with actors.
Really, it's not obvious? Of course you can: instead of shared memory you now have each actor having its own memory, instead of using locks and working on shared memory you now have messages and can ask actors to do something with their memory and send you the result back.
You just have to think a bit differently about your synchronization primitves. You don't have locks, you have a message queue and that is your synchronization primitive. A resource that should only be accessed by one thread is abstracted away using an actor, and the queue guarantees that only one process at the time has access, as the actor can only process one message at a time.
You can implement locks using actors if you really want to. An actor represents the state of the lock and stores which actor locked it and only responds to the unlock message from that actor and ignores all lock and unlock messages from all the other actors until it is unlocked.
We had to control various devices based on sensor data, but we also needed to make sure that the workload was distributed across the devices in an efficient way. To implement that, we had one actor per device that was solely responsible for adjusting the device output based on sensor data. Then we had another actor that was responsible for looking at the behavior of a cluster of devices and distributing the load between them. This "load distribution" actor wouldn't control the devices directly, but instead would send adjustments to the actors directly controlling the device.
I find it very natural to anthropomorphize actors. That is, if you were to think about how you would organize a group of people to do the work of the system (in a very Taylorist sort of way) the roles of those people map neatly onto the actors one would create.
One common pattern is the manager/supervisor/worker pattern[0]. I see this as mapping fairly neatly onto the project manager/people manager/employee structure that you see in many organizations.
[0] https://zxq9.com/archives/1311