Introduction to Actor Programming

Wilson de Carvalho

History

● The history of Actors goes back to the 70s, being originally proposed for Erlang;

● Emerged as a way to get scores of machines/CPUs to work together to solve large problems;

● Erlang + Actors used in AXD301, an Ericsson product that achieves nine nines of reliability.

Pitfalls in multithreading

● Thread starvation: all threads busy or all deadlocked. User may think system is ok.

● Race conditions: shared data changed by multiple threads simultaneously. Internal logic can be subverted.

● Deadlock: thread 1 locks resource A, thread 2 resource B, then as 2 attempts to lock A and 1 lock B, we have a deadlock.

Main idea

● Message passing;● Actors do not share state;● Actors only communicate through immutable

messages;● Actors do not talk to each other directly but

through actor references.

Why better?

● Not necessary:○ Manage locks;○ Think about how to protect shared data;○ Scale shared mutable state solution (tough job!).

● More protected from deadlocks, race conditions and starvation;

● Inside an actor we're safe.

Example

Example: sharing state

Example: message passing

1. Immutable messages

2. Asynchronous requests

3. Addresses instead of references

AddressTo(printOffice)

AddressTo(ticketAgent)

Message passing x Function calling

Fault tolerance

Scaling up

● 4096 threads per GB in Linux x64 (stack size is 256kB)

● ~2.7 million actors per GB in Akka

Scaling out

References

- Books:- Actors in Scala- Akka In Action- Programming in Scala 2ed