Attori: modelli, framework ed Erlang

1. Perche il modello ad attori

Il modello ad attori nasce come alternativa al multi-threading tradizionale per la programmazione concorrente e distribuita. L'idea centrale e che tutto nel sistema sia un attore: un'entita 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 piu rilevante nel panorama mainstream. Framework come Akka (ora Pecco sulla JVM), Erlang, HTML5 Web Workers e Dart Isolates sono esempi concreti di adozione di questo modello. La ragione principale e che gli attori offrono una via d'uscita dai problemi classici della programmazione concorrente: race condition, deadlock, complessita della sincronizzazione manuale.

Il Prof. Ricci ricorda come Alan Kay, padre della OOP, intendesse originariamente gli oggetti proprio come entita 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.

2. Il modello ad attori di Carl Hewitt

Introdotto da Carl Hewitt e colleghi al MIT negli anni '70 nel contesto dell'intelligenza artificiale, il modello ad attori e stato successivamente sviluppato da Gul Agha e Akinori Yonezawa negli anni '80 e '90. Il punto di partenza e la domanda: "come possiamo modellare il calcolo concorrente in modo matematico?"

La risposta e sorprendentemente semplice: l'attore e il primitivo universale del calcolo concorrente digitale. Tutto — incluse le strutture di controllo tradizionali (if, while, procedure) — puo essere modellato come pattern di scambio di messaggi tra attori.

1. 1973 — Hewitt pubblica "A Universal Modular ACTOR Formalism"
2. 1977 — "Viewing Control Structures as Patterns of Passing Messages", Journal of AI
3. 1986 — Gul Agha formalizza il modello nella sua tesi "Actors: A model of concurrent computation in distributed systems"
4. 1987 — Nasce Erlang in Ericsson per applicazioni telecom
5. 1990 — Agha pubblica "Concurrent Object Oriented Programming" su CACM
6. 2000+ — Akka (Scala/Java), Pecco (JVM), Web Workers, Dart Isolates

I tre pilastri del modello

Un attore e 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).

3. Primitive fondamentali: send, create, become

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

Un aspetto cruciale e che un attore puo 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.

4. Semantica macro-step e incapsulamento

Il modello ad attori introduce una semantica di esecuzione molto particolare: la semantica macro-step (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.

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]
    

Conseguenze della semantica macro-step

• Assenza di race condition — lo stato interno non e mai accessibile concorrentemente.
• Semplicita di ragionamento — il programmatore puo ragionare sul comportamento dell'attore come se fosse sequenziale.
• 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.

Incapsulamento dello stato

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

5. Framework Pecco (ex Akka) sulla JVM

Nella parte centrale della lezione, il Prof. Ricci introduce Pecco, un framework ad attori per l'ecosistema JVM (Java/Scala). Pecco e il successore open-source di Akka: quando Lightbend (l'azienda dietro Akka) ha cambiato licenza in Business Source License, la comunita ha forkato il cuore tecnologico sotto il nome Apache Pekko, che il corso chiama Pecco.

Le dipendenze necessarie per iniziare con Pecco includono il modulo core actor-type-typed e il modulo di logging basato su SLF4J. La versione typed dell'API e 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.

6. Actor system, behavior e actor ref

Il sistema ad attori ha una struttura gerarchica. L'ActorSystem e la radice: crea gli attori di primo livello. Ogni attore puo a sua volta essere padre di altri attori, formando un albero di supervisione. Questo e ispirato al modello di Erlang, dove la filosofia e "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 Pecco e il comportamento dell'attore: una funzione che prende un messaggio e un contesto e restituisce il prossimo behavior. E importante capire che il prossimo behavior non deve essere per forza lo stesso: un attore puo cambiare comportamento dinamicamente in risposta ai messaggi.

Creazione di un attore in Pecco

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 e il riferimento tramite cui si interagisce con un attore. E parametrizzato sul tipo T dei messaggi accettati: ActorRef<T>. Se si prova a inviare un messaggio di tipo sbagliato, il programma non compila.

7. Esempio Ping-Pong in Pecco

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 e chiaro: il messaggio Ping "incapsula" il protocollo di risposta portando con se il riferimento a chi deve rispondere. Questo evita la necessita di un meccanismo di sincronizzazione separato. Il Prof. Ricci sottolinea che questo e il modo idiomatico di fare request-response nel mondo ad attori: via messaggio con campo replyTo, non via chiamata bloccante.

8. Supervisione e fault tolerance

Uno degli aspetti piu potenti del modello ad attori e il meccanismo di supervisione, ispirato a Erlang. L'idea e 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").

Strategie di supervisione

Quando un attore figlio fallisce, il padre puo 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 e 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 puo 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).

9. Pattern di messaggistica: fire-and-forget, ask, reply

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 complessita.

Fire-and-forget (tell)

L'attore invia un messaggio e non si aspetta una risposta. E il caso piu 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. E il pattern idiomatico del mondo ad attori: preserva l'asincronia e non richiede blocking.

Ask pattern

Pecco fornisce anche l'operatore ask che restituisce una Future. Questo e 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 e utile ma "esce un po' dal modello puro". L'uso della Future introduce un meccanismo che non e nativo del modello ad attori. Tuttavia, quando usato con giudizio, risolve il problema dell'asynchronous spaghetti: si possono combinare piu ask in sequenza con thenCompose o in parallelo con Promise.all.

10. Erlang: processo leggero e mailbox

Erlang e un linguaggio funzionale sviluppato in Ericsson a partire dal 1987 per costruire applicazioni telecom. Insieme ad Ada, e considerato uno dei linguaggi concorrenti piu robusti mai adottati dall'industria. Il cuore di Erlang e la BEAM (Bogdan/Bjorn's Erlang Abstract Machine), una macchina virtuale che implementa un modello ad attori nativo.

In Erlang, gli attori si chiamano processi (non processi OS, ma entita logiche leggerissime). La BEAM puo gestire centinaia di migliaia di processi su una singola macchina. La creazione di un processo costa pochi microsecondi.

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
    

Processi vs Thread

11. Erlang: pattern matching e receive

Erlang e 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 lancia un nuovo processo e restituisce il PID (Process IDentifier). La send si fa con l'operatore !. La receive usa pattern matching con guardie per selezionare quale messaggio processare.

-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 rectangle is ~p~n",[3.14159*R*R]),
            loop();
        Other ->
            io:format("I don't know what the area of a ~p is ~n",[Other]),
            loop()
    end.

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 e un processo.

-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()}.

L'esempio della for comprehension in Erlang 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

12. Async programming: event loop e CPS

Il Prof. Ricci dedica una parte della lezione a inquadrare il modello ad attori nel contesto piu ampio della programmazione asincrona. L'event loop e il meccanismo fondamentale che sta sotto sia gli attori che la programmazione asincrona moderna.

Event loop

flowchart LR
    Q[Coda eventi] -->|estrai| EL[Event Loop]
    EL -->|dispatcher| H[Handler]
    H -->|completato| EL
    

Il pattern dell'event loop e semplice: un singolo thread attende eventi, li dispatca agli handler appropriati e ogni handler viene eseguito fino al completamento prima di servire l'evento successivo. E lo stesso pattern che sta sotto JavaScript, node.js, e — guarda caso — l'event loop incapsulato di ogni attore.

Continuation-Passing Style (CPS)

Il CPS e uno stile di programmazione in cui il controllo viene passato esplicitamente sotto forma di continuazione (un callback). Invece di restituire un valore, una funzione CPS chiama la continuazione con il risultato. Questo e il fondamento della programmazione asincrona basata su callback.

function loadUserPic(userId, ret) {
    findUserById(userId, (user) => {
        loadPic(user.picId, ret);
    });
}

loadUserPic('john', (pic) => {
    ui.show(pic);
});

13. Promise, async/await e coroutine

Per risolvere il callback hell, sono state introdotte le Promise. Una Promise e un oggetto che rappresenta il risultato futuro (o l'errore) di un'operazione asincrona. Puo trovarsi in tre stati: pending (creata, in attesa), resolved (completata con successo), rejected (completata con errore).

findUserById('john')
    .then(user => findPic(user.picId))
    .then(pic => ui.show(pic))
    .catch(err => console.error(err));

Promise.all([delayWithRand(1000), delayWithRand(2000)])
    .then(([r1, r2]) => console.log(r1, r2));

Async/await

L'evoluzione successiva e async/await, che permette di scrivere codice asincrono con uno stile sincrono. Una funzione async restituisce una Promise. L'operatore await sospende la funzione fino a quando la Promise non e risolta, senza bloccare il thread.

async function main() {
    console.log("Before");
    for (let i = 0; i < 3; i++) {
        await delay(1000);
        console.log("Step " + i);
    }
    console.log("After");
}

Coroutine

Il Prof. Ricci spiega che async/await e implementato usando le coroutine, una generalizzazione del concetto di subroutine che permette di sospendere e riprendere l'esecuzione. Le coroutine sono la base per implementare lightweight threads (fibers, virtual threads). Kotlin, Go (goroutine) e Java (virtual threads da JDK 19) usano questo meccanismo.

suspend fun greetAfter(name: String, delayMillis: Long) {
    delay(delayMillis)
    println("Hello, $name")
}

fun main() = runBlocking {
    val result = async {
        delay(1000)
        100
    }
    println("${result.await()}")
}

14. Message delivery semantics e ordinamento

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

Ordinamento

Il modello ad attori garantisce un ordinamento sender-receiver: se A invia il messaggio M1 e poi M2 a B, M1 viene consegnato prima di M2. Tuttavia, non c'e garanzia di ordinamento tra coppie diverse: se A invia M1 a B e M2 a C, M2 potrebbe arrivare prima di M1.

15. Testing degli attori con Pecco

Pecco 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 perche la semantica asincrona puo nascondere bug sottili. Il test kit di Pecco 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.

16. 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 funzionalita 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) anziche 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 Pecco 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 della prossima lezione).

Verifica le tue conoscenze