source: doc/theses/colby_parsons_MMAth/text/actors.tex @ d964c39

% ======================================================================
% ======================================================================
\chapter{Concurrent Actors}\label{actors}
% ======================================================================
% ======================================================================

% C_TODO: add citations
Before discussing \CFA's actor system in detail, it is important to first describe the actor model, and the classic approach to implementing an actor system.

\section{The Actor Model}
The actor model is a paradigm of concurrent computation, where tasks are broken into units of work that are distributed to actors in the form of messages \cite{Hewitt73}. Actors execute asynchronously upon receiving a message and can modify their own state, make decisions, spawn more actors, and send messages to other actors. The actor model is an implicit model of concurrency. As such, one strength of the actor model is that it abstracts away many considerations that are needed in other paradigms of concurrent computation. Mutual exclusion, and locking are rarely relevant concepts to users of an actor model, as actors traditionally operate on local state.

% C_TODO: make and insert a classic actor system diagram

\section{Classic Actor System}
An implementation of the actor model with a community of actors is called an actor system. Actor systems largely follow the actor model, but differ in some ways. While the definition of the actor model provides no restrictions on message ordering, actor systems tend to guarantee that messages sent from a given actor i to actor j will arrive at actor j in the order they were sent. Another way an actor system varies from the model is that actors are often allowed to access non-local state. When this occurs it can complicate the implementation as this will break any mutual exclusion guarantees given by accessing only local state.

Actor systems \cite{} have often been implemented as an actor-centric system. As such they are constructed as a set of actors that are scheduled and run on some underlying threads. Each actor has their own mailbox for receiving messages. When they receive messages in their mailbox, actors are moved from idle to ready queues and then scheduled on a thread.