Il modello ad attori

1. Perché il modello ad attori

Il modello ad attori nasce come alternativa al multi-threading tradizionale per la programmazione concorrente e distribuita. L'idea centrale è che tutto nel sistema sia un attore: un'entità autonoma, puramente reattiva, che comunica solo tramite scambio asincrono di messaggi.

Nella lezione, il Prof. Ricci sottolinea come il modello ad attori sia diventato sempre più rilevante nel panorama mainstream. Framework come Akka (ora Pekko sulla JVM), Erlang, HTML5 Web Workers e Dart Isolates sono esempi concreti di adozione di questo modello. La ragione principale è che gli attori offrono una via d'uscita dai problemi classici della programmazione concorrente: race condition, deadlock, complessità della sincronizzazione manuale.

Il Prof. Ricci ricorda come Alan Kay, padre della OOP, intendesse originariamente gli oggetti proprio come entità che comunicano tramite message passing. Il modello ad attori realizza compiutamente questa visione: ogni attore ha un identificatore unico, una mailbox (coda di messaggi) e un comportamento che determina come reagire ai messaggi ricevuti.

L'idea centrale è: everything is an actor. Ogni entità computazionale è un attore, con:

• un identificatore unico (actor reference);
• uno stato incapsulato (non accessibile direttamente dall'esterno);
• un comportamento (la logica di reazione ai messaggi);
• una mailbox (coda di messaggi in ingresso).

Il modello in 90 secondi

Nella lezione di ripasso il messaggio chiave è condensato così: un actor è uno stato incapsulato che reagisce solo ai messaggi. Niente accesso diretto allo stato altrui, niente controllo condiviso, solo comunicazione asincrona.

send(other, "ping", self(), "ciao")
// invio asincrono: il mittente continua subito

public void ping(ActorName caller) {
  send(caller, "alive", self());
  become(new WaitingForAck());
}

2. Il modello di Carl Hewitt

Il modello Actor fu originariamente introdotto da Carl Hewitt e colleghi al MIT negli anni '70, nel contesto dell'intelligenza artificiale. Successivamente sviluppato da Gul Agha e Akinori Yonezawa negli anni '80 e '90 come unificazione fra OOP e concorrenza: la cosiddetta Concurrent Object-Oriented Programming. Il punto di partenza è la domanda: "come possiamo modellare il calcolo concorrente in modo matematico?"

La risposta è sorprendentemente semplice: l'attore è il primitivo universale del calcolo concorrente digitale. Il modello Actor è una teoria matematica che tratta gli attori come i primitivi universali della computazione concorrente. Tutto — incluse le strutture di controllo tradizionali (if, while, procedure) — può essere modellato come pattern di scambio di messaggi tra attori. Ogni entità nel sistema è un attore con un identificatore univoco e una mailbox (coda di messaggi).

1. 1973 — Carl Hewitt introduce il modello Actor con "A Universal Modular ACTOR Formalism", come teoria matematica per il calcolo concorrente
2. 1977 — Hewitt pubblica "Viewing Control Structures as Patterns of Passing Messages" (Journal of AI)
3. 1986 — Gul Agha formalizza il modello nella tesi "Actors: A Model of Concurrent Computation in Distributed Systems"
4. 1987 — Yonezawa e Tokoro curano "Concurrent Object Oriented Programming" (MIT Press); nello stesso anno nasce Erlang in Ericsson per applicazioni telecom
5. 1990 — Agha pubblica su CACM: il modello Actor come unificazione di OOP e concorrenza
6. 2009 — Akka: framework actor industrial-grade per la JVM
7. 2000+ — Erlang, Scala/Akka (poi Pekko), HTML5 Web Workers, Dart isolates e sistemi cloud-native portano gli attori nel mainstream

Un attore è dunque un'entità computazionale che incapsula stato, comportamento e un flusso di controllo logico. A differenza degli oggetti classici, gli attori sono autonomi e reattivi: lavorano solo quando ricevono un messaggio.

flowchart LR
    subgraph A1 [Attore A]
        S1[(Stato)] & C1[Comportamento] & ID1[ID]
    end
    subgraph A2 [Attore B]
        S2[(Stato)] & C2[Comportamento] & ID2[ID]
    end
    A1 -->|messaggio asincrono| A2
    A2 -->|messaggio asincrono| A1
    

I tre pilastri del modello

Un attore è definito da tre elementi essenziali:

• Un identificatore unico — permette ad altri attori di inviargli messaggi senza conoscere la sua posizione fisica (location transparency).
• Una mailbox — una coda (tipicamente FIFO) dove i messaggi in arrivo vengono accodati.
• Un comportamento — il codice che definisce come l'attore reagisce al messaggio corrente (send, create nuovi attori, become).

flowchart LR
    A1[Attore 1] -->|send msg| A2[Attore 2]
    A2 -->|send reply| A1
    A1 -->|create| A3[Attore 3]
    A3 -->|become| A3b[Attore 3 con nuovo behavior]
    

Nonostante le origini accademiche, il modello Actor ha trovato ampia adozione industriale: Erlang per sistemi telecom estremamente robusti, Akka/Pekko per applicazioni enterprise su JVM, HTML5 Web Workers per il parallelismo nel browser, Dart isolates, e molti altri framework. È considerato un'alternativa valida al multithreading tradizionale per costruire sistemi concorrenti scalabili.

3. Le tre primitive: send, create, become

Il modello ad attori definisce solo tre primitive per comporre il comportamento di un attore. Ogni altra costruzione (sincronizzazione, ordinamento, pattern) è derivabile da queste tre.

Send è per la programmazione concorrente ciò che l'invocazione di procedura è per la programmazione sequenziale: il mattoncino fondamentale. Create è l'analogo dell'astrazione di procedura: permette di definire nuovi attori. Become permette all'attore di cambiare il proprio comportamento (e quindi il proprio stato locale) per il messaggio successivo, dando agli attori una history-sensitive behaviour necessaria per modellare oggetti mutabili condivisi.

Un aspetto cruciale è che un attore può comunicare solo con attori di cui conosce l'identificatore. Questi identificatori possono essere scambiati all'interno dei messaggi, permettendo la costruzione di topologie di comunicazione dinamiche.

Un'altra osservazione importante: a differenza degli oggetti classici dell'OOP, gli attori incapsulano anche il controllo — un oggetto normale non ha un flusso di controllo proprio (è passivo), mentre un attore è intrinsecamente attivo. Tuttavia, gli attori sono disaccoppiati dai thread fisici del sistema operativo: sono entità logiche. Come le goroutine di Go, una piattaforma attori può gestire milioni di attori su pochi thread fisici.

4. Semantica: macro-step, incapsulamento, fairness

La semantica del modello Actor si fonda su cinque aspetti chiave:

Macro-step semantics (run-to-completion)

Quando un attore riceve un messaggio, l'intero handler viene eseguito completamente prima di passare al messaggio successivo. Questo elimina alla radice il problema delle race condition sullo stato interno. Gli handler devono però avere un comportamento non bloccante — l'unico punto di blocco è gestito dal ciclo eventi dell'attore.

flowchart LR
    A[Attore] --> B[mailbox: msg1, msg2, msg3]
    B --> C[estrai msg1]
    C --> D[esegui handler]
    D --> E[msg1 completato]
    E --> F[estrai msg2]
    F --> G[esegui handler]
    G --> H[msg2 completato]
    

Le conseguenze della macro-step semantics sono profonde:

• Assenza di race condition — lo stato interno non è mai accessibile concorrentemente: un handler non viene mai interrotto da un altro handler sullo stesso attore.
• Semplicità di ragionamento — il programmatore può ragionare sul comportamento dell'attore come se fosse sequenziale: ogni messaggio viene elaborato in un contesto stabile e consistente.
• Problema dello "spaghetti asincrono" — la logica applicativa viene frammentata in handler separati, rendendo il codice difficile da seguire quando ci sono conversazioni complesse tra attori.
• Nessun blocking call — un handler non deve mai bloccare, altrimenti blocca l'intero event loop dell'attore: se un handler deve fare una richiesta a un altro attore e attendere la risposta, non può semplicemente bloccarsi — deve organizzarsi in callback/handler separati.

La macro-step semantics è identica a quella delle architetture event-driven: GUI management, JavaScript con callback, Node.js. Tutte condividono lo stesso modello: un ciclo eventi che estrae un evento, esegue il gestore fino al completamento, poi passa al prossimo evento.

Incapsulamento dello stato

Un attore non può accedere direttamente allo stato interno di un altro attore. L'unico modo per interagire con un attore è inviargli un messaggio. Questo incapsulamento è molto più forte di quello dell'OOP classico: non solo i dati, ma anche il flusso di controllo è incapsulato. L'attore decide quando e come processare un messaggio, e può persino rimandare messaggi (stashing).

Fairness

La fairness è un altro punto cruciale. Hewitt voleva un modello efficace anche nei sistemi distribuiti, quindi stabilì che: se un attore invia un messaggio, questo sarà eventualmente recapitato alla mailbox del destinatario. Non c'è garanzia sul tempo, né sull'ordine. Questa assunzione è volutamente debole per essere realizzabile in ambienti distribuiti reali (diversamente da UDP, che non garantisce neppure la consegna).

Location transparency

La location transparency permette di inviare messaggi a un attore conoscendo solo la sua identità (actor ref), senza sapere se risiede sullo stesso processo, sulla stessa macchina, o su un nodo remoto. Questo è ciò che rende il modello Actor naturalmente adatto a sistemi distribuiti: lo stesso meccanismo funziona per attori locali e remoti.

State Explorer: ciclo di vita con become

5. L'event loop degli attori

L'implementazione pratica del modello attore si basa su un event loop implicito o esplicito. L'architettura di controllo di un attore è un message loop (implicitamente gestito dal framework):

Event loop implicito

loop {
  msg <- waitForMsg()            // attesa bloccante (solo qui)
  handler <- selectHandler(msg)  // dispatch del messaggio
  execute(handler)               // esecuzione atomica
}

Esempi: ActorFoundry, Akka/Pekko, Vert.x, Web Workers.

Event loop esplicito

Il programmatore scrive il loop di ricezione e usa pattern matching. Esempio: Erlang.

Il widget seguente mostra il ciclo di vita di un attore visto dal punto di vista del message loop:

6. Implementazioni: panoramica e ActorFoundry

Il modello Actor ha diverse implementazioni, con varianti semantiche significative. Le più importanti presentate a lezione sono tre: Erlang (linguaggio nativo), Akka/Pekko (framework JVM), e ActorFoundry (framework accademico Java).

counter(Sum) ->
    receive
        {inc} ->
            counter(Sum + 1);
        {getValue, Pid} ->
            Pid ! {count_value, Sum},
            counter(Sum)
    end.

public class MyUntypedActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
        if (message instanceof String) {
            log.info("Received String message: {}", message);
            getSender().tell("received");
        } else unhandled(message);
    }
}

public class PingActor extends Actor {
    ActorName otherPinger;
    @message
    public void start(ActorName other) {
        otherPinger = other;
        send(otherPinger, "ping", self(), "...");
    }
}

Explicit vs Implicit receive

Una differenza fondamentale tra i framework è come gestiscono il message loop:

• Implicit receive (Akka/Pekko, ActorFoundry): il loop di ricezione dei messaggi è nascosto all'interno del framework. Il programmatore definisce solo gli handler. Ciò è semplice ma porta all'async spaghetti.
• Explicit receive (Erlang): il programmatore scrive esplicitamente il loop receive ... end, con pattern matching e guardie. Più flessibile e con maggiore controllo, ma anche più verboso e con più disciplina richiesta. Supporta la selective receive con guardie.

ActorFoundry: esempio concreto in Java

ActorFoundry è un framework accademico basato su Java, sviluppato dal gruppo di Gul Agha all'Università dell'Illinois (UIUC). Include ottimizzazioni e idee da altri lavori di ricerca come Kilim. Mostra in modo chiaro e minimalista le primitive fondamentali del modello: il programmatore estende la classe Actor e definisce i metodi che saranno invocati alla ricezione di un messaggio.

Il codice seguente mostra un classico ping-pong fra attori:

Analizziamo gli elementi chiave:

• extends Actor: ogni attore estende la classe base Actor
• @message: annotation che marca un metodo come gestore di messaggi — quando arriva un messaggio, il framework invoca automaticamente il metodo corrispondente
• send(target, "messageName", args...): primitiva di invio asincrono — il primo argomento è l'attore destinatario, il secondo è una stringa che identifica il tipo di messaggio (corrispondente al nome del metodo)
• self(): restituisce l'identificatore dell'attore corrente (di tipo ActorName)
• create(Classe.class): crea un nuovo attore specificando la classe che ne definisce il comportamento

In PingBoot, l'attore di boot crea due attori PingActor e avvia il protocollo inviando a pinger1 il messaggio "start" con il riferimento a pinger2. I due attori si scambiano messaggi "ping" e "alive", stampando il tutto sullo stdout tramite l'attore standard stdout.

7. Pekko (ex Akka): attori sulla JVM

Akka è il framework per attori più maturo a livello industriale per l'ecosistema JVM. Scritto in Scala ma utilizzabile da entrambi i linguaggi, offre un ricco set di funzionalità tra cui tolleranza ai guasti stile Erlang ("let it crash"), clustering, stashing, e pattern di supervisione e di messaggistica avanzati. Supporta sia untyped actors (Java) che typed actors (Scala).

import akka.actor.UntypedActor;
import akka.event.Logging;
import akka.event.LoggingAdapter;

public class MyUntypedActor extends UntypedActor {
  LoggingAdapter log = Logging.getLogger(getContext().system(), this);

  public void onReceive(Object message) throws Exception {
    if (message instanceof String) {
      log.info("Received String message: {}", message);
      getSender().tell("received");
    } else
      unhandled(message);
  }
}

import akka.actor.Actor
import akka.actor.Props
import akka.event.Logging

class MyActor extends Actor {
  val log = Logging(context.system, this)
  def receive = {
    case "test" => log.info("received test")
    case _      => log.info("received unknown message")
  }
}

L'API typed di Pekko

Le dipendenze necessarie per iniziare con Pekko includono il modulo core typed e il modulo di logging basato su SLF4J. La versione typed dell'API è un'evoluzione importante: nell'API classica (untyped) si poteva mandare qualsiasi messaggio a qualsiasi attore, anche messaggi che l'attore non era in grado di gestire. Con l'API typed, ogni attore dichiara il tipo T dei messaggi che accetta, e il compilatore garantisce la correttezza a tempo di compilazione.

Actor system, behavior e actor ref

Il sistema ad attori ha una struttura gerarchica. L'ActorSystem è la radice: crea gli attori di primo livello. Ogni attore può a sua volta essere padre di altri attori, formando un albero di supervisione. Questo è ispirato al modello di Erlang, dove la filosofia è "Let It Crash": gli attori possono fallire, ma il padre (supervisore) decide come reagire.

flowchart TD
    S[ActorSystem] --> A1[Attore A]
    S --> A2[Attore B]
    A1 --> C1[Attore C - figlio di A]
    A1 --> C2[Attore D - figlio di A]
    A2 --> E1[Attore E - figlio di B]
    

Un behavior in Pekko è il comportamento dell'attore: una funzione che prende un messaggio e un contesto e restituisce il prossimo behavior. È importante capire che il prossimo behavior non deve essere per forza lo stesso: un attore può cambiare comportamento dinamicamente in risposta ai messaggi.

Creazione di un attore in Pekko

import org.apache.pekko.actor.typed.*;
import org.apache.pekko.actor.typed.javadsl.*;

public class HelloWorld {
    public static Behavior<String> create() {
        return Behaviors.setup(context -> {
            return Behaviors.receiveMessage(message -> {
                System.out.println("Hello " + message);
                return Behaviors.same();
            });
        });
    }

    public static void main(String[] args) {
        ActorSystem<String> system = ActorSystem.create(HelloWorld.create(), "hello-system");
        system.tell("World!");
    }
}

L'actor ref è il riferimento tramite cui si interagisce con un attore. È parametrizzato sul tipo T dei messaggi accettati: ActorRef<T>. Se si prova a inviare un messaggio di tipo sbagliato, il programma non compila.

Esempio Ping-Pong in Pekko

Il Prof. Ricci mostra l'esempio classico per illustrare l'interazione tra attori: il protocollo Ping-Pong. Due attori si scambiano messaggi: Pinger e Ponger. Il messaggio Ping contiene un campo replyTo con l'actor ref a cui rispondere.

public interface PingProtocol { }
public static final class Ping implements PingProtocol {
    public final ActorRef<PongProtocol> replyTo;
    public Ping(ActorRef<PongProtocol> replyTo) {
        this.replyTo = replyTo;
    }
}
public interface PongProtocol { }
public static final class Pong implements PongProtocol { }

public static Behavior<PingProtocol> pingerBehavior() {
    return Behaviors.setup(context -> Behaviors.receiveMessage(msg -> {
        if (msg instanceof Ping p) {
            p.replyTo.tell(new Pong());
            return Behaviors.same();
        }
        return Behaviors.unhandled();
    }));
}

public static Behavior<PongProtocol> pongerBehavior() {
    return Behaviors.setup(context -> Behaviors.receiveMessage(msg -> {
        if (msg instanceof Pong) {
            System.out.println("Ricevuto Pong!");
            return Behaviors.same();
        }
        return Behaviors.unhandled();
    }));
}

Il pattern è chiaro: il messaggio Ping "incapsula" il protocollo di risposta portando con sé il riferimento a chi deve rispondere. Questo evita la necessità di un meccanismo di sincronizzazione separato. Il Prof. Ricci sottolinea che questo è il modo idiomatico di fare request-response nel mondo ad attori: via messaggio con campo replyTo, non via chiamata bloccante.

8. Erlang: processi, mailbox e pattern matching

Erlang è il linguaggio che ha portato il modello attore nella produzione industriale: probabilmente il linguaggio di programmazione concorrente più robusto e utilizzato dall'industria, insieme ad Ada. Sviluppato in Ericsson a partire dal 1987 per costruire applicazioni telecom, è un linguaggio funzionale che si basa su un modello a processi leggeri (non thread OS) che comunicano via message passing asincrono. Il cuore di Erlang è la BEAM (Bogdan/Björn's Erlang Abstract Machine), una macchina virtuale che implementa un modello ad attori nativo: i processi Erlang sono concettualmente identici agli attori.

flowchart LR
    subgraph BEAM[BEAM Virtual Machine]
        P1[Processo 1
mailbox]
        P2[Processo 2
mailbox]
        P3[Processo N
mailbox]
    end
    P1 -->|invia messaggio| P2
    P2 -->|invia messaggio| P3
    P3 -->|invia messaggio| P1
    

Caratteristiche principali

• La BEAM è una macchina virtuale concorrente che gestisce processi come entità completamente logiche, non legate a thread o processi OS
• La creazione di processi è estremamente economica — centinaia di migliaia di processi possono essere creati su un singolo host, con costo di pochi microsecondi
• È un linguaggio funzionale: pattern matching, assenza di variabili globali, moduli per organizzare le funzioni
• La filosofia è: everything is a process — non c'è memoria condivisa, quindi anche un contatore è un processo

Processi vs Thread

Primitive fondamentali

Erlang è un linguaggio funzionale: un programma descrive una serie di funzioni, con pattern matching per determinare quale clausola eseguire. Le variabili iniziano con la lettera maiuscola (come in Prolog). Non esistono variabili globali.

La primitiva spawn crea un nuovo processo (attore) specificando modulo, nome funzione e parametri (o una fun anonima). Restituisce un PID (Process IDentifier) che identifica univocamente il processo. L'operatore ! invia un messaggio a un processo: Pid ! Message. La receive selettiva estrae un messaggio dalla mailbox del processo usando pattern matching:

% Creazione processo
Pid = spawn(fun () -> account(0) end).
% Invio messaggio
Pid ! Message.
% Ricezione con pattern matching
receive
  Pattern1 [ when Guard1 ] -> Expression1;
  Pattern2 [ when Guard2 ] -> Expression2;
  ...
end

Il processo si blocca finché non trova un messaggio nella coda che matcha un pattern con guardia verificata.

Esempio: area server

% Esempio Erlang: area server (dalle slide)
-module(area_server0).
-export([loop/0]).

loop() ->
    receive
        {rectangle, Width, Ht} ->
            io:format("Area of rectangle is ~p~n", [Width * Ht]),
            loop();
        {circle, R} ->
            io:format("Area of circle is ~p~n", [3.14159 * R * R]),
            loop();
        Other ->
            io:format("I don't know what ~p is~n", [Other]),
            loop()
    end.

% Nell'interprete:
% 1> Pid = spawn(fun area_server0:loop/0).
% 2> Pid ! {rectangle, 3, 4}.
% Area of rectangle is 12

Notare che: (1) ogni caso della receive termina con ; tranne l'ultimo che termina con .; (2) ogni caso chiama ricorsivamente loop() per rimettersi in ascolto del messaggio successivo; (3) il pattern Other cattura qualsiasi messaggio non riconosciuto.

Esempio Counter in Erlang

Il Prof. Ricci mostra come in Erlang anche un semplice contatore sia un processo. Non esiste memoria condivisa: tutto è un processo. Lo stato (il valore corrente) vive nel parametro della funzione ricorsiva.

-module(counter).
-export([start/0]).

start() -> loop(0).

loop(Sum) ->
    receive
        {inc} ->
            loop(Sum + 1);
        {getValue, Pid} ->
            Pid ! {count_value, Sum},
            loop(Sum)
    end.

% 1> Pid = spawn(counter, start, []).
% 2> Pid ! {inc}.
% 3> Pid ! {getValue, self()}.

Esempio: account bancario

account(Balance) ->
  receive
    {deposit, Amount, Whom} -> Whom ! {deposit_receipt, Amount},
                               account(Balance + Amount);
    {balance, Whom} -> Whom ! {balance, Balance},
                       account(Balance);
    {withdrawal, Amount, Whom} when Amount > Balance ->
                               Whom ! overdraft, account(Balance);
    {withdrawal, Amount, Whom} -> Whom ! {withdrawal_receipt, Amount},
                               account(Balance - Amount)
  end.

L'esempio con la for comprehension mostra come creare decine di migliaia di processi in pochi millisecondi, misurando il tempo di spawn:

-module(processes).
-export([max/1]).

max(N) ->
    Max = erlang:system_info(process_limit),
    io:format("Maximum allowed processes:~p~n",[Max]),
    statistics(runtime),
    statistics(wall_clock),
    L = for(1, N, fun() -> spawn(fun() -> wait() end) end),
    {_, Time1} = statistics(runtime),
    {_, Time2} = statistics(wall_clock),
    ...

% Output per N=20000:
% Process spawn time=5.5 (9.4) microseconds

9. Pattern di messaggistica e actor idioms

Il modello ad attori prevede diversi pattern di interazione, ciascuno con i propri casi d'uso. Il Prof. Ricci li presenta in ordine crescente di complessità.

Fire-and-forget (tell)

L'attore invia un messaggio e non si aspetta una risposta. È il caso più semplice e comune: si usa actorRef.tell(messaggio) o l'operatore !. Esempio: inviare un Increment a un contatore senza curarsi del risultato.

Request-response con replyTo

L'attore mittente include nel messaggio un campo replyTo: ActorRef<Risposta>. Il destinatario usa questo riferimento per inviare la risposta. È il pattern idiomatico del mondo ad attori: preserva l'asincronia e non richiede blocking.

Ask pattern

Pekko fornisce anche l'operatore ask che restituisce una Future. Questo è utile quando si vuole interagire con un attore da codice non-actor (es. da un main) o quando serve una risposta ma non si vuole implementare il protocollo manualmente.

import static org.apache.pekko.actor.typed.javadsl.AskPattern.ask;
import java.time.Duration;
import java.util.concurrent.CompletionStage;

CompletionStage<String> risposta = ask(
    actorRef,
    replyTo -> new RichiediDati(replyTo),
    Duration.ofSeconds(5),
    system.scheduler()
);

risposta.thenAccept(valore -> {
    System.out.println("Ricevuto: " + valore);
});

Il Prof. Ricci fa notare che ask è utile ma "esce un po' dal modello puro". L'uso della Future introduce un meccanismo che non è nativo del modello ad attori. Tuttavia, quando usato con giudizio, risolve il problema dell'asynchronous spaghetti: si possono combinare più ask in sequenza con thenCompose o in parallelo con Promise.all.

Actor Idioms (Schumacher, AGERE! 2012)

Come ogni paradigma, anche il modello Actor ha i suoi pattern ricorrenti. I principali sono:

• Future: un attore che funge da proxy per un risultato non ancora disponibile. È un modo per implementare comunicazione sincrona (RPC-like) all'interno di un modello asincrono, massimizzando la concorrenza. Ha tre stati: iniziale (nessun valore, nessun cliente), attesa (clienti accodati), risolto (clienti notificati, valore immutabile). Il future può essere passato ad altri attori prima di essere risolto.
• Serializer: un attore che serializza l'accesso a una risorsa condivisa, garantendo che le operazioni siano eseguite una alla volta sulla sua mailbox.
• Fork-Join: un pattern per dividere un compito in sotto-compiti paralleli e aggregare i risultati, simile all'omonimo pattern nel mondo dei thread ma realizzato interamente via message passing.
• Scheduler: un attore che gestisce il passaggio del testimone.

Messaging Patterns (V. Vernon)

• Messaging Channels: Point-to-Point, Publish-Subscribe, Dead Letter, Message Bus.
• Message Construction: Command, Document, Event, Request-Reply, Correlation Identifier.
• Message Routing: Content-based Filter, Message Filter, Process Manager, Message Broker.
• Message Transformation: Envelope Wrapper, Content Enricher, Content Filter.

Timeline storica del message passing

1. 1970 — Brinch-Hansen introduce l'async message passing per l'RC4000.
2. 1971 — Bob Balzer introduce il concetto di communication port.
3. 1973 — Carl Hewitt introduce il modello Actor all'MIT.
4. 1974 — Dijkstra introduce le guarded commands.
5. 1978 — Hoare formalizza CSP (Communicating Sequential Processes).
6. 1986 — Gul Agha pubblica "Actors: A Model of Concurrent Computation".
7. 1987 — Ericsson sviluppa Erlang per telecomunicazioni.
8. 2007 — Go language (Google): goroutine, canali, select.
9. Oggi — Akka/Pekko, Dart isolates, Web Workers, attori mainstream.

10. Spaghetti asincrono: future, stashing e LSC

La macro-step semantics semplifica il ragionamento sugli attori ma introduce un problema serio: la logica applicativa viene frammentata in un insieme non strutturato di handler/callback, ciascuno dei quali reagisce a un evento specifico. Quando un flusso di lavoro richiede una sequenza di passi, ogni passo diventa un handler separato. Il professore chiama questo il problema degli "spaghetti asincroni" (asynchronous spaghetti), rifacendosi a [RS-12].

Esempio: sin(x) * cos(y)

L'esempio classico dalle slide: un attore deve valutare l'espressione sin(x)*cos(y) delegando i calcoli a due attori specializzati (sinActor e cosActor). Con la semantica macro-step, l'attore principale non può bloccarsi in attesa dei risultati. Deve:

1. Inviare x a sinActor e y a cosActor.
2. Ricevere il risultato da sinActor in un handler.
3. Ricevere il risultato da cosActor in un altro handler.
4. Quando entrambi i risultati sono arrivati, calcolare il prodotto.

Questo frammenta la logica in tre handler separati, perdendo la struttura sequenziale naturale dell'algoritmo: ogni risposta richiede un handler diverso, e bisogna tracciare lo stato per sapere se l'altra risposta è già arrivata. La letteratura [RS-12] documenta approfonditamente questo problema.

Soluzioni proposte

• Futures/Promises: oggetti proxy per un risultato non ancora disponibile.
• Promise pipelines: compongono future in sequenza.
• Stashing (Akka/Pekko): mettere da parte i messaggi che non possono essere processati ora.
• Local Synchronization Constraints (ActorFoundry): condizioni booleane che abilitano/disabilitano la ricezione di messaggi.

class ActorWithProtocol extends Actor with Stash {
  def receive = {
    case "open" =>
      unstashAll()
      context.become({
        case "write" => // do writing...
        case "close" => unstashAll(); context.unbecome()
        case msg => stash()
      }, discardOld = false)
    case msg => stash()
  }
}

@Disable(messageName = "put")
public Boolean disablePut(Integer x) {
  if (bufferReady) { return (tail == bufferSize); }
  else return true;
}

Lo stash in dettaglio

Lo stash è una coda implicita separata dalla mailbox principale:

• stash(): accoda il messaggio corrente nello stash.
• unstashAll(): re-inserisce tutti i messaggi stashati nella mailbox principale.

Il pattern classico è: in uno stato transitorio, i messaggi non gestibili vengono stashati; quando si arriva allo stato giusto (o scade un timer), si fa unstashAll() e si riprocessano.

// Pattern Akka: stash per gestire un protocollo a stati
Behaviors.receive { (ctx, msg) =>
  msg match {
    case "open" =>
      unstashAll()
      Behaviors.receiveMessage {
        case "write" => // scrivi...
        case "close" =>
          unstashAll()
          context.unbecome()
        case _ => stash()
      }
    case _ => stash()
  }
}

RPC-like messaging

Un pattern comune è simulare chiamate RPC in un modello puramente asincrono. Il client invia una richiesta e poi controlla i messaggi in arrivo. Se arriva la risposta, la processa; altrimenti, bufferizza i messaggi non correlati per elaborazione futura. Questo protocollo è implementabile con le primitive di base ma è complesso — per questo i framework offrono supporto diretto, come la primitiva call in ActorFoundry. Il pattern Future è alla base della comunicazione RPC-like nel modello actor: un attore-future fa da proxy per un risultato non ancora disponibile e, quando il valore viene calcolato, notifica tutti gli attori in attesa.

11. Il problema della proattività

Gli attori sono entità puramente reattive: lavorano solo quando ricevono un messaggio. Ma come si modella un comportamento proattivo, orientato al raggiungimento di obiettivi tramite un piano di azioni? Il professore dedica una parte significativa della lezione a questo problema, che ritiene concettualmente importante. Le soluzioni classiche includono: dividere l'attore in più attori interagenti, oppure il self-sending di messaggi.

L'esempio concreto: un attore deve calcolare e stampare i primi 100 numeri, ma deve poter ricevere un messaggio stop che interrompe la stampa. Un attore puramente reattivo non può iniziare da solo la stampa — deve aspettare un messaggio che glielo richieda. La soluzione proposta dal professore è il self-sending: l'attore invia messaggi a se stesso per procedere incrementalmente nel lavoro.

// Messaggio di start
send me, "iterat_print", i, end

// Handler per iterat_print
if (not stopped)
  print(i)
  if (i < end)
    send me, "iterat_print", i+1, end

// Handler per stop
stopped = true

Il pattern è semplice ma profondo: ogni stampa è un passo atomico gestito da un messaggio. Se arriva un messaggio stop prima del completamento, l'attore smette di auto-inviarsi messaggi e la stampa si ferma. L'attore rimane reattivo (ogni messaggio è una reazione), ma l'auto-invio crea un effetto proattivo complessivo.

Il problema della proattività è affrontato anche dalla ricerca: esistono proposte per estendere il modello Actor con astrazioni che permettano di specificare comportamenti proattivi (piani, goal) mantenendo la reattività come meccanismo di interazione. Tuttavia, nel modello di base, il self-sending rimane la tecnica più diffusa e pragmatica.

12. Supervisione e fault tolerance

Uno degli aspetti più potenti del modello ad attori è il meccanismo di supervisione, ispirato a Erlang. L'idea è che gli attori falliscano (lanciando eccezioni), ma il padre-supervisore decide come reagire. Non si cerca di prevenire tutti i fallimenti: si accetta che accadano e si fornisce un meccanismo di recovery ("Let It Crash").

Lo state explorer seguente mostra il ciclo di vita completo di un attore, incluso lo stato di fallimento gestito dal supervisore:

Strategie di supervisione

Quando un attore figlio fallisce, il padre può applicare diverse strategie:

Il meccanismo di supervisione ha un effetto collaterale molto importante: la pulizia automatica delle risorse. Se un attore padre fallisce, tutti i figli vengono automaticamente fermati e le loro risorse rilasciate. Questo è molto diverso dal mondo dei thread, dove un thread orfano continua a vivere e il programmatore deve implementare meccanismi ad hoc per chiudere file, rilasciare lock, ecc.

Behaviors.setup(context -> {
    ActorRef<MyMsg> child = context.spawn(
        Behaviors.supervise(childBehavior())
            .onFailure(SupervisorStrategy.restart()),
        "child-actor"
    );
    return childBehavior();
});

Il Prof. Ricci menziona anche la funzione watch: un padre può osservare un figlio e ricevere una notifica ChildFailed o Terminated quando termina. Questo permette al padre di reagire alla terminazione (es. cleanup aggiuntivo o terminazione a catena del sistema).

13. Delivery semantics e ordinamento dei messaggi

Un tema importante toccato nella lezione riguarda le garanzie di consegna dei messaggi tra attori. Pekko (come Akka ed Erlang) adotta una semantica at-most-once: i messaggi possono essere persi (per crash, problemi di rete, ecc.), ma non saranno mai duplicati.

Ordinamento

Le implementazioni pratiche come Pekko rafforzano il modello di base: viene garantito un ordinamento sender-receiver. Se A invia il messaggio M1 e poi M2 a B, M1 viene consegnato prima di M2. Tuttavia, non c'è garanzia di ordinamento tra coppie diverse: se A invia M1 a B e M2 a C, M2 potrebbe arrivare prima di M1. Per gestire la sincronizzazione e l'ordinamento locale, alcuni framework offrono inoltre vincoli di sincronizzazione locale (LSC in ActorFoundry) o lo stashing di Akka/Pekko, visti nella sezione 10.

14. Testing degli attori

Pekko fornisce un modulo di testing integrato con ScalaTest e JUnit. Il test kit permette di creare un ActorSystem di test, spawnare attori e verificare che i messaggi vengano scambiati correttamente.

import org.apache.pekko.actor.testkit.typed.javadsl.*;

@Test
public void testPingPong() {
    var testKit = ActorTestKit.create();
    var probe = testKit.createTestProbe();
    var pinger = testKit.spawn(pingerBehavior());

    pinger.tell(new Ping(probe.ref()));
    probe.expectMessageClass(Pong.class);
}

Il Prof. Ricci sottolinea l'importanza di testare gli attori, soprattutto perché la semantica asincrona può nascondere bug sottili. Il test kit di Pekko permette di: (1) spawnare attori in un ambiente controllato, (2) usare probe per catturare i messaggi in uscita, (3) impostare timeout per evitare test che si bloccano.

15. Errori comuni e best practice

Il Prof. Ricci conclude la lezione con una serie di raccomandazioni pratiche su cosa evitare quando si sviluppa con gli attori.

Cosa evitare

Raccomandazioni positive

• Frammentare: identificare funzionalità specifiche e creare attori specializzati per ciascuna.
• Protocolli espliciti: definire i protocolli di interazione come strutture dati (es. sealed interface/class in Java).
• Message-driven: preferire sempre il passaggio di messaggi diretto (con replyTo) anziché meccanismi ibridi come ask.
• Sfruttare la gerarchia: organizzare gli attori in alberi di supervisione per una gestione robusta dei fallimenti.
• Testing sistematico: usare il test kit di Pekko per verificare il comportamento degli attori.

Il Prof. Ricci ricorda che il modello ad attori consente di definire in modo esplicito il protocollo di interazione tra componenti, offre un modo strutturato per gestire fallimenti e ciclo di vita, e costituisce la base per passare dalla programmazione concorrente a quella distribuita (argomento del prossimo capitolo).

Verifica le tue conoscenze