This module has shown many tools for protecting shared mutable state: locks, Interlocked, concurrent collections, snapshots. They all have one thing in common: they manage the problem. The actor model abolishes it. There is no shared state anymore, only state that belongs to exactly one actor, and messages that actors send to each other. This lesson builds an actor from the building blocks you already know, uses it to replace the lock of the booking from lesson 3.11.6, and shows where an actor inside its own process reaches its limits. That is exactly where K4 begins with Orleans.

Three rules

An actor is a small piece of a program with three properties:

  1. It has state, and only it does. Nobody but the actor reads or writes its data. No other code holds a reference to it.
  2. It receives messages. Whoever wants something from the actor sends it a message into its mailbox and, if they ask, gets an answer back.
  3. It handles one message after the other. Never two at once. While it handles a message, its state changes only through the actor itself.

Everything else follows from the third rule: check-then-act is no longer a race, because no other message can come between the check and the act. A deadlock of two locks does not exist, because there are no locks. Concurrency arises between actors, not inside them: a hundred calendars, a hundred actors, a hundred bookings at the same time, but in each calendar one after the other.