Il modello ad attori

1. Che cos'è un attore

Il modello nasce come alternativa ai thread con memoria condivisa: tutto è un attore, e gli attori non condividono nulla. Ognuno ha quattro elementi:

• un indirizzo (identità, actor reference) a cui gli altri inviano messaggi;
• una mailbox, la coda dei messaggi ricevuti e non ancora elaborati;
• uno stato privato, che nessun altro può leggere o scrivere;
• un comportamento, cioè il codice che decide come reagire al prossimo messaggio.

Un oggetto dell'OOP incapsula lo stato, ma i suoi metodi girano nel thread di chi li chiama: è un componente passivo. Un attore incapsula anche il flusso di controllo: decide lui quando elaborare un messaggio, quindi è un componente attivo, pur essendo puramente reattivo. È l'idea originale di Alan Kay per l'OOP, dove il punto chiave era lo scambio di messaggi. Gli attori sono entità logiche, non thread del sistema operativo: un runtime ne esegue migliaia o milioni su pochi thread.

Le tre primitive

Nella formulazione di Gul Agha (1986), che sviluppa il modello di Carl Hewitt (MIT, 1973), un attore che elabora un messaggio può fare solo tre cose:

Un attore può inviare messaggi solo agli attori di cui conosce l'indirizzo: quelli che ha creato, quelli che conosceva alla creazione e quelli ricevuti dentro un messaggio. Poiché gli indirizzi viaggiano nei messaggi, la topologia della comunicazione cambia a run time.

Cinque proprietà semantiche

Il macro-step è la proprietà che rende gli attori semplici da ragionare: dentro un handler l'attore si comporta come un programma sequenziale, perché nessun altro handler dello stesso attore può interromperlo. Non servono lock sullo stato. La condizione è che l'handler non si blocchi mai: un attore bloccato non elabora più nessun messaggio. È la stessa regola del never-blocking nell'event loop di JavaScript, e gli attori ne condividono sia i vantaggi sia i problemi (sezione 5).

La fairness è volutamente debole: Hewitt voleva un modello realizzabile anche su reti reali, dove si può promettere al più che un messaggio prima o poi arrivi.

2. Dov'è il ciclo degli eventi

Dietro ogni attore c'è un ciclo di questo tipo, e il macro-step è il corpo di un'iterazione:

loop {
  msg     <- waitForMsg()          // l'unico punto in cui l'attore si blocca
  handler <- selectHandler(msg)    // sceglie l'handler in base al messaggio
  execute(handler)                 // macro-step: fino in fondo
}

Le implementazioni si dividono secondo chi scrive questo ciclo:

• Receive implicita (Pekko/Akka, ActorFoundry; lo stesso schema hanno i verticle di Vert.x e i Web Worker). Il ciclo sta nel framework, incapsulato nell'attore, e il programmatore scrive solo gli handler. È semplice, ma ogni risposta attesa diventa un handler separato.
• Receive esplicita (Erlang). Il programmatore scrive receive … end dove vuole, dentro una funzione ricorsiva. La receive è selettiva: estrae il primo messaggio che corrisponde a uno dei pattern con guardia e lascia gli altri in mailbox. Così un processo può fermarsi ad aspettare proprio la risposta che gli serve, a metà di un calcolo, al prezzo di più disciplina e di mailbox che possono riempirsi di messaggi mai estratti.

3. Tre implementazioni, un'idea

// Il protocollo: i messaggi sono tipi. Ping porta con sé a chi rispondere.
record Ping(ActorRef<Pong> replyTo) {}
record Pong() {}

static Behavior<Ping> ponger() {
  return Behaviors.receive(Ping.class)
      .onMessage(Ping.class, ping -> {
        ping.replyTo().tell(new Pong());       // send
        return Behaviors.same();               // stesso comportamento
      }).build();
}

static Behavior<Pong> pinger(ActorRef<Ping> ponger, int left) {
  return Behaviors.setup(ctx -> {
    ponger.tell(new Ping(ctx.getSelf()));
    return Behaviors.receive(Pong.class)
        .onMessage(Pong.class, pong -> left > 1
            ? pinger(ponger, left - 1)        // become: nuovo stato
            : Behaviors.stopped())
        .build();
  });
}

Behavior<Void> main = Behaviors.setup(ctx -> {
  ActorRef<Ping> p = ctx.spawn(ponger(), "ponger");  // create
  ctx.spawn(pinger(p, 3), "pinger");
  return Behaviors.empty();
});
ActorSystem.create(main, "ping-pong");

account(Balance) ->
  receive
    {deposit, Amount, Whom} ->
        Whom ! {deposit_receipt, Amount},
        account(Balance + Amount);             % become: nuovo stato
    {balance, Whom} ->
        Whom ! {balance, Balance},
        account(Balance);
    {withdrawal, Amount, Whom} when Amount > Balance ->
        Whom ! overdraft,                      % guardia: prelievo rifiutato
        account(Balance);
    {withdrawal, Amount, Whom} ->
        Whom ! {withdrawal_receipt, Amount},
        account(Balance - Amount)
  end.

Pid = spawn(fun() -> account(0) end).         % create
Pid ! {deposit, 100, self()}.                  % send

public class PingActor extends Actor {
  @message
  public void start(ActorName other) {
    send(other, "ping", self());               // send: asincrono
  }
  @message
  public void ping(ActorName caller) {
    send(stdout, "println", "ping da " + caller);
    send(caller, "alive", self() + " è vivo");
  }
  @message
  public void alive(String reply) {
    send(stdout, "println", reply);
  }
}

public class PingBoot extends Actor {
  @message
  public void boot() {
    ActorName a = create(PingActor.class);     // create
    ActorName b = create(PingActor.class);
    send(a, "start", b);
  }
}

4. Come parlano gli attori

• Fire-and-forget (tell): invio senza attendere risposta. È il caso base.
• Request-response con replyTo: la richiesta contiene l'indirizzo a cui rispondere, come Ping nell'esempio Pekko. Il protocollo sta tutto nei messaggi e nessuno si blocca: è la forma idiomatica, quella che Ricci raccomanda.
• Ask: Pekko crea un attore temporaneo che riceve la risposta e restituisce una CompletionStage, con un timeout obbligatorio. Serve soprattutto da codice che non è un attore, come il main, o per comporre più risposte.

CompletionStage<Pong> reply = AskPattern.ask(
    ponger, replyTo -> new Ping(replyTo),
    Duration.ofSeconds(3), system.scheduler());
reply.thenAccept(pong -> System.out.println("risposta arrivata"));

Ask «esce un po' dal modello»: introduce future e timeout che il modello non prevede. Inoltre la callback gira fuori dal macro-step dell'attore, quindi non deve toccarne lo stato. Dentro un attore si usa ctx.ask (o pipeToSelf), che ritrasforma la risposta in un messaggio per l'attore.

5. Il prezzo del macro-step

Un handler non può aspettare. Consideriamo l'esempio delle slide: un attore deve calcolare sin(x) · cos(y) delegando i due calcoli agli attori Sin e Cos. In un programma sequenziale sarebbero due chiamate e un prodotto. Qui invece un handler invia le due richieste e termina. Le risposte arrivano in due handler diversi, in un ordine qualsiasi, e l'attore deve ricordarsi nello stato quale risultato ha già. Con conversazioni più lunghe il flusso logico si disperde tra handler scollegati: è lo spaghetti asincrono (Ricci e Santi, AGERE! 2012), lo stesso problema del callback hell.

Laboratorio: un runtime ad attori in miniatura

Qui fai tu da runtime. Consegna un messaggio in viaggio alla mailbox del destinatario, poi fai eseguire a un attore un macro-step. I messaggi della stessa coppia mittente → destinatario arrivano nell'ordine di invio, come in Pekko; per il resto l'ordine lo scegli tu, o lo sceglie Passo a caso. Gli scenari corrispondono a questa sezione e alla successiva.

Le soluzioni

• Future e promise: un proxy per il risultato non ancora disponibile, che si può passare ad altri prima che si risolva. Le promise pipeline compongono le future in sequenza.
• Stash (Pekko): i messaggi che l'attore non può gestire nello stato attuale vengono messi da parte e reinseriti in mailbox quando lo stato cambia. È lo scenario «Stash» del laboratorio.
• Local synchronization constraints (ActorFoundry): per ogni tipo di messaggio una condizione dice quando non può essere elaborato. I messaggi disabilitati aspettano in una coda a parte, e si separa il quando elaborare un messaggio dal come.
• Receive esplicita (Erlang): il processo aspetta la risposta con una receive selettiva, che è il modo di ottenere un'interazione simile a una RPC.

static Behavior<FileCmd> closed() {
  return Behaviors.withStash(100, stash ->
      Behaviors.receive(FileCmd.class)
          .onMessage(Open.class, o -> stash.unstashAll(open("")))  // rimette in mailbox
          .onMessage(Write.class, w -> { stash.stash(w); return Behaviors.same(); })
          .build());
}

@Disable(messageName = "put")          // put non si elabora mentre…
public Boolean disablePut(Integer x) {
  return !bufferReady || tail == bufferSize;   // …il buffer non è pronto o è pieno
}

Proattività: mandarsi messaggi

Un attore puramente reattivo non può «decidere» di fare qualcosa: può solo reagire. Come si scrive allora un attore che stampa i numeri da 1 a 100 e deve anche poter essere fermato da un messaggio stop? Un ciclo for dentro l'handler occuperebbe un unico macro-step, e lo stop resterebbe in mailbox fino alla fine. La soluzione è spezzare il lavoro in passi, ognuno innescato da un messaggio che l'attore invia a se stesso:

on start(end):       send self, print(1, end)
on print(i, end):    if not stopped:
                       print i
                       if i < end: send self, print(i+1, end)
on stop:             stopped := true

Tra un passo e l'altro lo stop può arrivare ed essere elaborato: prova lo scenario «Proattività» nel laboratorio. L'attore resta reattivo, ma il risultato è un comportamento che procede da solo. L'altra soluzione, parziale anch'essa, è dividere l'attore in più attori che interagiscono. In Pekko si ottiene lo stesso con i timer (capitolo 16).

6. Guasti e garanzie di consegna

Supervisione: let it crash

Dall'esperienza di Erlang viene l'idea di non difendere ogni riga dai guasti: un attore che incontra un errore fallisce, e decide il suo supervisore, cioè l'attore che lo ha creato. Gli attori formano così un albero con radice nell'ActorSystem.

ActorRef<Cmd> child = ctx.spawn(
    Behaviors.supervise(worker())
        .onFailure(IllegalStateException.class, SupervisorStrategy.restart()),
    "worker");
ctx.watch(child);   // il padre riceverà il segnale Terminated / ChildFailed

Nell'API typed di Pekko un attore che lancia un'eccezione per default viene fermato. Restart e resume si chiedono con supervise, mentre l'escalation passa per watch: il padre riceve ChildFailed e, se non lo gestisce, fallisce a sua volta. Un effetto utile dell'albero è la pulizia: quando un padre si ferma, si fermano anche tutti i suoi figli, mentre un thread orfano continua a vivere.

Consegna e ordinamento

Pekko, come Akka ed Erlang, garantisce at-most-once: se serve di più, conferme e ritrasmissioni si scrivono nel protocollo. Il modello di base non garantisce nemmeno l'ordine. Pekko aggiunge l'ordine per coppia mittente → destinatario: se A invia M1 e poi M2 a B, B li riceve in quest'ordine. Tra coppie diverse invece non c'è alcun ordine, nemmeno causale. Nello scenario «Ordinamento» del laboratorio B riceve m3 prima di m1, anche se m3 è una conseguenza di un messaggio inviato dopo m1. Per un ordine globale serve un attore sequenziatore, o gli orologi logici del capitolo 17.

La location transparency fa sì che tutto questo valga uguale tra nodi diversi: il passaggio al cluster è nel capitolo 16.

7. In pratica

Per i test, Pekko offre un ActorTestKit che avvia un sistema di prova, e delle probe che fanno da destinatari e verificano i messaggi ricevuti. Anche il test di un solo attore ha bisogno del runtime, quindi somiglia più a un test di integrazione che a uno unitario.

ActorTestKit kit = ActorTestKit.create();
TestProbe<Pong> probe = kit.createTestProbe(Pong.class);
ActorRef<Ping> ponger = kit.spawn(ponger());
ponger.tell(new Ping(probe.getRef()));
probe.expectMessageClass(Pong.class);
kit.shutdownTestKit();

Le domande sull'assignment 3 (struttura degli attori e dei messaggi) sono nella pagina di preparazione.

Verifica le tue conoscenze