Il messaggio chiave e semplice: un actor e uno stato incapsulato che reagisce solo ai messaggi. Niente accesso diretto allo stato altrui, niente controllo condiviso, solo comunicazione asincrona.
Actor = mailbox + stato + comportamento. Il controllo vive nel messaggio che arriva, non in una variabile condivisa.
| Concetto | In pratica |
|---|---|
send | Invia un messaggio senza bloccare il mittente |
create | Istanzia un nuovo actor con un comportamento preciso |
become | Cambia il comportamento per il prossimo messaggio |
| macro-step | Un handler si completa prima di passare al messaggio successivo |
send(other, "ping", self(), "ciao")
// invio asincrono: il mittente continua subitopublic void ping(ActorName caller) {
send(caller, "alive", self());
become(new WaitingForAck());
}Gli actor semplificano il ragionamento sulle race, ma diventano difficili da leggere se spezzi la logica in troppi handler senza un protocollo chiaro.
Un handler non deve bloccare. Se ti serve attesa, buffering o chaining: sposta la logica nel protocollo, non in un while infinito.
Siamo alla chiusura della parte introduttiva: da qui in poi il focus si sposta verso la parte distribuita, usando gli strumenti che avete gia visto per leggere protocolli, concorrenza e coordinazione.
Nel ripasso di oggi tornano utili anche clock logici e vector clock: non come teoria isolata, ma come strumenti per capire l'ordine degli eventi nei sistemi distribuiti.
| Asse | Domanda da saper rispondere |
|---|---|
| Actor model | Perche elimina shared mutable state e riduce le race? |
| Asincronia | Come si coordina una risposta quando il mittente non aspetta? |
| Parte distribuita | Come ragioniamo su ordine, causalita e protocolli? |
Oggi: ripasso degli actors e orientamento finale. L'obiettivo e consolidare il modello mentale, non aggiungere complessita nuova.
Venerdi: modulo 4.1 e passaggio alla parte distribuita. Qui i concetti vanno letti come estensione naturale di cio che gia conoscete.
Lunedi: anticipazione del quarto assignment, cosi avete tempo di leggere la traccia con calma e prepararvi prima della consegna.
Il riferimento e sul sito, insieme a LabActivity11. In una lezione breve come questa il punto non e svelare il testo, ma dirvi come affrontarlo bene: cercate il protocollo, i ruoli e gli stati, non solo i dettagli superficiali.
Prima di scrivere codice, mappa la traccia in tre cose: chi parla con chi, quali messaggi esistono, e quali invarianti devono restare vere.
1. Leggi la traccia e individua gli attori/ruoli
2. Elenca i messaggi e le risposte possibili
3. Definisci lo stato minimo di ogni actor
4. Disegna i casi limite: ordine, assenza di messaggi, errori
5. Solo dopo passa all'implementazioneSe la traccia parla di request-reply, buffering o coordinazione, pensa subito in termini di mailbox e transizioni di stato. E il modo piu rapido per non perderti.
// schema mentale minimo
Actor client = ...;
Actor server = ...;
client.send(server, "request", id, payload);
// server decide se rispondere subito, accodare o cambiare statoPerche lo stato resta incapsulato e il controllo passa solo attraverso messaggi asincroni, non tramite memoria condivisa.
Che un handler viene eseguito fino in fondo prima che l'actor prenda in carico il messaggio successivo.
Tradurre la traccia in ruoli, messaggi, stato minimo e invarianti prima di scrivere implementazione.
Blocchi lunghi, wait attive e loop infiniti: rompono la reattivita del sistema.