Go, Canali e Modelli a Scambio di Messaggi

1. Roadmap e organizzazione del corso

Il professore apre la lezione con una panoramica di dove siamo arrivati nel programma. Siamo ormai alla fine del corso. La lezione precedente (2026-04-17) ha introdotto il modulo 3.1 sui modelli a scambio di messaggi, con la macro-suddivisione tra comunicazione sincrona e asincrona. Oggi si entra nel vivo con un laboratorio pratico su Go, un linguaggio che implementa il modello sincrono attraverso i canali.

Il calendario rimanente prevede: venerdì una lezione sugli attori (modello asincrono), lunedì prossimo un laboratorio con Nicolas su Scala e il framework Akka. Chiude la terza parte del corso. Il professore anticipa anche il terzo assignment: due mini-progetti sulla falsariga del secondo, con la possibilita di applicare sia l'approccio ad attori sia quello a canali.

2. Go: un linguaggio per la concorrenza

Go (o Golang) e un linguaggio a tipizzazione statica sviluppato da Robert Griesemer, Rob Pike e Ken Thompson in Google a partire dal 2007. La sintassi deriva liberamente dal C, con l'aggiunta di garbage collection, type safety, capacita di type inference, tipi built-in come array dinamici (slice) e mappe chiave-valore, e una ricca libreria standard.

La caratteristica che lo rende centrale per questo corso e il supporto built-in alla concorrenza: goroutine (processi leggeri), canali, e select. Le radici concorrenti di Go affondano nel CSP (Communicating Sequential Processes) di Hoare (1978). Il motto del linguaggio e emblematico:

Go non e un linguaggio object-oriented nel senso classico. Non ha classi ne ereditarieta. Ha invece struct per incapsulare dati, metodi che si definiscono esternamente alle struct, e interfacce per il polimorfismo. I progettisti hanno deliberatamente distillato solo gli aspetti dell'OOP che considerano significativi, scartando il resto.

3. Array e Slice

Il professore mostra la sintassi per dichiarare array in Go, commentando con ironia che la notazione — nome, dimensione, tipo — gli sembra esteticamente discutibile, ma evidentemente ci sono canoni diversi.

// Dichiarazione di array: nome, dimensione, tipo
var frimes [5]int                         // array di 5 interi
var colors [2]string = [2]string{"rosso", "blu"}  // array di 2 stringhe
primes := [6]int{2, 3, 5, 7, 11, 13}     // type inference, inizializzazione

Gli array in Go sono a dimensione fissa. Per lavorare con sequenze dinamiche si usano le slice, che sono porzioni di array con dimensione variabile. Le slice sono il modo fondamentale di gestire collezioni in Go: sono flessibili, supportano operatori di aggiunta e affettatura, e sono reference a porzioni di un array sottostante.

// Slice: vista dinamica su un array
s := primes[1:4]           // slice degli elementi da indice 1 a 3
s = append(s, 17)          // aggiunge elemento; se necessario, alloca nuovo array
fmt.Println(len(s), cap(s)) // lunghezza e capacita della slice

4. Metodi e Interfacce: Go non e OOP

Go adotta un approccio peculiare alla programmazione: separa nettamente i dati (struct) dal comportamento (metodi e funzioni). I metodi si dichiarano esternamente alla struct, utilizzando un receiver esplicito:

type Vertex struct {
    X, Y float64
}

// Metodo con receiver per valore
func (v Vertex) Abs() float64 {
    return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

// Metodo con receiver per riferimento (modifica l'originale)
func (v *Vertex) Scale(f float64) {
    v.X = v.X * f
    v.Y = v.Y * f
}

Le interfacce in Go sono soddisfatte implicitamente: un tipo implementa un'interfaccia semplicemente avendo tutti i metodi richiesti, senza bisogno di una dichiarazione implements esplicita. Questo si chiama structural typing (o duck typing statico).

type Stringer interface {
    String() string
}

// Vertex implementa automaticamente Stringer
func (v Vertex) String() string {
    return fmt.Sprintf("(%g, %g)", v.X, v.Y)
}

5. Goroutine: attori leggeri e scheduler M:N

Le goroutine sono il cuore della concorrenza in Go. Una goroutine e un thread leggero gestito dal runtime di Go, non dal sistema operativo. Si crea con la semplice parola chiave go:

go myFunction()       // avvia myFunction in una nuova goroutine
go func() {           // oppure con funzione anonima
    fmt.Println("Ciao dal goroutine!")
}()

Il runtime di Go implementa uno scheduler M:N che mappa M goroutine su N thread OS (tipicamente uno per core). Questo permette di avere milioni di goroutine attive contemporaneamente senza il costo di un thread OS per ciascuna. Lo scheduler gestisce in modo ottimizzato l'esecuzione, la sospensione e la ripresa delle goroutine, anche quando interagiscono in modo sincronizzato sui canali.

6. Canali: comunicazione CSP sincrona

I canali sono il meccanismo di comunicazione tra goroutine. Un canale e un tubo tipizzato attraverso cui si inviano e ricevono valori. La creazione avviene con make:

ch := make(chan int)      // canale senza buffer: sincrono!
ch := make(chan int, 10)  // canale con buffer di 10: asincrono

La sintassi per inviare e ricevere usa l'operatore freccia <-:

ch <- 42         // send: invia 42 sul canale ch
val := <-ch      // receive: riceve un valore da ch e lo assegna a val

7. Rendez-vous sincrono: quando send incontra receive

Il rendez-vous e il cuore del modello sincrono. Il professore spiega che nella comunicazione sincrona, il trasferimento del dato sul canale ch avviene solo quando il puntatore di controllo del sender e sulla send, e quello del receiver e sulla receive. Entrambi si bloccano fino all'incontro.

Il professore illustra questo meccanismo con l'esempio classico del produttore-consumatore. Con la semantica sincrona, il trasferimento avviene solo quando il produttore P e al punto p2 (send) E il consumatore Q e al punto q1 (receive):

// Produttore
func producer(ch chan<- int) {
    for i := 0; ; i++ {
        x := produce(i)   // p1
        ch <- x           // p2: bloccante finche Q non riceve
        // p3: continua
    }
}

// Consumatore
func consumer(ch <-chan int) {
    for y := range ch {   // q1: bloccante finche P non invia
        consume(y)        // q2
    }
}

func main() {
    ch := make(chan int)  // canale sincrono (senza buffer)
    go producer(ch)
    consumer(ch)
}

Nel codice sopra, chan<- int indica un canale solo-send (produttore), mentre <-chan int indica un canale solo-receive (consumatore). Go permette di vincolare la direzione dei canali a livello di tipo, aumentando la sicurezza.

8. Select: guarded communication in Go

Come gestire messaggi che possono arrivare su piu canali contemporaneamente? Il problema e lo stesso della guarded communication introdotta da Dijkstra nel 1974. Go lo risolve con l'istruzione select, che permette a una goroutine di attendere su piu operazioni di canale contemporaneamente.

select {
case msg1 := <-ch1:
    fmt.Println("Ricevuto da ch1:", msg1)
case msg2 := <-ch2:
    fmt.Println("Ricevuto da ch2:", msg2)
case ch3 <- 42:
    fmt.Println("Inviato 42 su ch3")
default:
    fmt.Println("Nessun canale pronto: esco senza bloccare")
}

Il select si blocca finche uno dei case non puo procedere. Se piu case sono pronti, ne sceglie uno in modo non deterministico (random uniforme). Se c'e il default, viene eseguito immediatamente se nessun canale e pronto (non-blocking select).

Un pattern molto utile e il timeout con select:

select {
case msg := <-ch:
    fmt.Println("Ricevuto:", msg)
case <-time.After(2 * time.Second):
    fmt.Println("Timeout dopo 2 secondi")
}

Qui time.After crea un canale che riceve un valore dopo il tempo specificato. Se la ricezione da ch non avviene entro 2 secondi, il timeout scatta.

9. Lab: producer-consumer, pipeline e million-goroutine

Il professore dedica una parte significativa della lezione a mostrare esempi pratici di programmazione concorrente in Go. Ecco i principali:

9.1 Canali direzionali e sincronizzazione

Il primo esempio mostra come creare goroutine che comunicano attraverso un canale. Il main attende la ricezione prima di procedere, dimostrando la sincronizzazione intrinseca:

func main() {
    ch := make(chan string)
    go func() {
        ch <- "Ciao dalla goroutine!"
    }()
    msg := <-ch
    fmt.Println(msg)
}

9.2 Producer-consumer con canale bufferizzato

Il secondo esempio estende il pattern a piu produttori e consumatori, usando un canale bufferizzato per disaccoppiare le fasi:

func worker(id int, jobs <-chan int, results chan<- int) {
    for j := range jobs {
        fmt.Printf("Worker %d lavora su job %d\n", id, j)
        results <- j * 2
    }
}

func main() {
    jobs := make(chan int, 100)
    results := make(chan int, 100)
    // Avvia 3 worker
    for w := 1; w <= 3; w++ {
        go worker(w, jobs, results)
    }
    // Invia 9 job
    for j := 1; j <= 9; j++ {
        jobs <- j
    }
    close(jobs)
    // Raccogli risultati
    for r := 1; r <= 9; r++ {
        <-results
    }
}

9.3 Million-goroutine challenge

Il professore fa una dimostrazione dal vivo: creare un milione di goroutine che comunicano via canali. Il codice crea un milione di agenti (goroutine) ciascuno con il proprio canale, invia un messaggio a ciascuno, e riceve le risposte. La creazione richiede circa 3 secondi principalmente a causa della stampa su standard output. Senza la stampa, e molto piu veloce.

const N = 1_000_000

func myAgent(id int, ch chan string) {
    msg := <-ch
    _ = msg
}

func main() {
    channels := make([]chan string, N)
    for i := 0; i < N; i++ {
        ch := make(chan string)
        channels[i] = ch
        go myAgent(i, ch)
    }
    for i := 0; i < N; i++ {
        channels[i] <- fmt.Sprintf("Messaggio %d", i)
    }
    for i := 0; i < N; i++ {
        <-channels[i]
    }
}

Il professore mostra anche come il compilatore Go rilevi variabili non utilizzate (è un errore!): quando si riceve da un canale ma non si usa il valore ricevuto, si assegna a _ (blank identifier) per soddisfare il compilatore.

10. Exchange Values Problem: tre strategie a confronto

Il problema dello scambio di valori e un classico esempio di coordinazione peer-to-peer. Abbiamo N processi, ciascuno con un valore intero locale. L'obiettivo e che ogni processo conosca il minimo e il massimo di tutti i valori. Il professore propone di implementare in Go le tre strategie viste nel modulo 3.1.

11. Dining Philosophers con message passing

Il problema dei filosofi a cena viene rivisitato in chiave message passing, senza memoria condivisa. Il professore presenta due soluzioni: centralizzata (un Waiter unico) e distribuita (un Waiter per forchetta).

11.1 Soluzione centralizzata con un Waiter

Un singolo processo Waiter funge da allocatore di risorse (forchette). Riceve richieste dai filosofi e concede le forchette quando sono entrambe disponibili. Se non lo sono, accoda la richiesta.

chan getForks(int,int,chan);
chan releaseForks(int,int,chan);

process Waiter[i:0..N-1] {
    List<Request> pending = ...;
    boolean availForks[0..N-1] = {false,...};
    do receive getForks(fork1,fork2, ReplyChanID)
    -> if availForks[fork1] && availForks[fork2]
        availForks[fork1] = false;
        availForks[fork2] = false;
        send ReplyChanID(fork1,fork2)
    else pending.add(new Request(Reply,fork,fork2));
    [] receive releaseForks(fork1,fork2)
    -> availForks[fork1] = true;
        availForks[fork2] = true;
        foreach Request r in pending
            if (availForks[r.fork1] && availForks[r.fork2])
                pending.remove(r);
                send req.ReplyChanID(req.fork1,req.fork2)
    od
}

Il filosofo interagisce cosi:

process Philo[i:0..N-1, chan reply] {
    int first = i;
    int second = (i+1)%N;
    loop {
        think();
        send getForks(first,second,reply)
        receive reply(first,second)
        eat();
        send releaseForks(first,second)
    }
}

11.2 Soluzione distribuita: un Waiter per forchetta

In questa versione, ogni forchetta ha il proprio processo Waiter. I filosofi acquisiscono le forchette seguendo il protocollo di gerarchia delle risorse (prendere prima la forchetta con indice minore) per evitare deadlock.

process Waiter[i:0..N-1] {
    loop {
        receive getFork[i]();
        send getForkReply[i]();
        receive releaseFork[i]();
        send releaseForkReply[i]();
    }
}

process Philosopher[i:0..N-1] {
    int first = i; second = (i+1)%N;
    if (second < first) { first = second; second = i; }
    loop {
        think();
        send getFork[first](); receive getForkReply[first]();
        send getFork[second](); receive getForkReply[second]();
        eat();
        send releaseFork[first](); receive releaseForkReply[first]();
        send releaseFork[second](); receive releaseForkReply[second]();
    }
}

12. Active Resource Manager via canali

Il professore mostra come il pattern del monitor passivo per l'allocazione di risorse possa essere implementato come processo attivo che comunica via canali. La tabella seguente (dalle slide) mette in corrispondenza i concetti:

Il processo ResAllocator usa un ciclo con guarded communication per gestire richieste di ACQUIRE e RELEASE, mantenendo una coda dei clienti in attesa:

process ResAllocator {
    int avail = MAXUNITS; queue pending; set units;
    op_kind kind; res_id id; int clientID;
    while (true) {
        receive request(clientID, kind);
        if (kind == ACQUIRE) {
            if (avail > 0) { // risorsa disponibile subito
                avail = avail - 1;
                id = remove(units);
                send reply[clientID](id);
            } else { // accoda la richiesta
                insert(pending, clientID);
            }
        } else if (kind == RELEASE) {
            if empty(pending) { // nessuno in attesa: restituisci
                insert(units, id); avail++;
            } else { // c'e un pending: passa direttamente
                remove(pending, clientID);
                send reply[clientID](id);
            }
        }
    }
}

13. Rendez-vous in Ada

Il linguaggio Ada implementa il rendez-vous in modo diretto attraverso il meccanismo di entry e accept. Un task dichiara nel suo interfaccia pubblico delle entry, e nel corpo del task implementa ogni entry con un blocco accept. Il task chiamante usa la chiamata a entry (simile a una chiamata di procedura, ma e una comunicazione tra task).

task Gourmet is
    entry Make_A_Hot_Dog;
end Gourmet;

task body Gourmet is
begin
    Put_Line("Sono pronto a fare hot dog per te");
    for Index in 1..4 loop
        accept Make_A_Hot_Dog do
            delay 0.8;
            Put_Line("Salsiccia nel panino con senape");
        end Make_A_Hot_Dog;
    end loop;
    Put_Line("Non ho piu hot dog");
end Gourmet;

Il task chiamante (cliente):

for Index in 1..4 loop
    Gourmet.Make_A_Hot_Dog;          -- chiamata bloccante
    Put_Line("Mangio l'hot dog");
end loop;

L'esecuzione produce la sequenza vista nelle slide: il Gourmet annuncia la disponibilita, per 4 volte prepara un hot dog (con ritardo di 0.8 secondi) mentre il cliente mangia, poi il Gourmet esaurisce le scorte. Il cliente, che chiama con un ritardo minore (0.1 s), rimane in attesa sul accept finche il Gourmet non completa la preparazione.

14. Reactive Programming: flussi di dati asincroni

Il professore dedica la parte finale della lezione alla programmazione reattiva (modulo 2.2), partendo dal presupposto che sia le CPS (Continuation Passing Style) sia le Promise gestiscono computazioni asincrone che producono un singolo risultato. Ma nelle applicazioni moderne e sempre piu comune dover gestire flussi di dati asincroni (streams).

La programmazione reattiva e un paradigma orientato ai flussi di dati e alla propagazione del cambiamento. E fortemente legata al pattern Observer e alla programmazione event-driven. E stata introdotta negli anni '90, ma oggi e fondamentale per lo sviluppo di applicazioni web reattive e Big Data.

Le principali librerie reattive sono le Reactive Extensions (Rx), disponibili per tutti i principali linguaggi (RxJS, RxJava, RxScala, RxPython, ecc.). L'idea centrale e che un Observable<T> rappresenta un flusso di dati a cui ci si sottoscrive con un Observer<T>.

// Rx.NET: Observable sequence
IObservable<int> source = Observable.Range(1, 10);
IDisposable subscription = source.Subscribe(
    x => Console.WriteLine("OnNext: {0}", x),
    ex => Console.WriteLine("OnError: {0}", ex.Message),
    () => Console.WriteLine("OnCompleted")
);
subscription.Dispose();

Interfacce Observer/Observable

Le interfacce fondamentali di Rx sono elegantemente semplici:

interface IObservable<T> {
    IDisposable Subscribe(IObserver<T> observer);
}

interface IObserver<T> {
    void OnNext(T value);      // nuovo dato disponibile
    void OnError(Exception e); // errore nel flusso
    void OnCompleted();         // flusso terminato
}

Il professore specifica: "Nothing happens until you subscribe." La configurazione della pipeline e dichiarativa; i dati iniziano a fluire solo quando un subscriber si collega.

15. Hot vs Cold e Backpressure

Il professore introduce due concetti chiave per comprendere i flussi reattivi: la distinzione tra stream hot e cold, e il meccanismo di backpressure.

15.1 Cold streams (freddi)

Un flusso cold inizia a generare elementi solo quando viene osservato (subscribed). Ogni subscriber riceve tutti gli elementi del flusso dal principio, indipendentemente dal momento in cui si sottoscrive. E come un file: se lo leggi da capo, vedi tutti i dati.

15.2 Backpressure

La backpressure e un meccanismo fondamentale per gestire la differenza di velocita tra produttore e consumatore. Quando un produttore e molto piu veloce del consumatore, si crea un accumulo che puo portare a esaurimento della memoria. La backpressure permette al consumatore di "spingere all'indietro" un segnale che dice al produttore di rallentare.

Il professore spiega che la backpressure trasforma il modello push puro in un modello push-pull ibrido: il downstream puo fare pull di N elementi se sono disponibili, ma se non lo sono, l'upstream li pusha quando prodotti.

// In Project Reactor: backpressure esplicita
Flux.range(1, 1000)
    .subscribe(new BaseSubscriber<Integer>() {
        @Override
        protected void hookOnSubscribe(Subscription s) {
            request(10);  // chiede 10 elementi alla volta
        }
        @Override
        protected void hookOnNext(Integer v) {
            System.out.println(v);
            request(1);   // ne chiede 1 dopo ogni ricezione
        }
    });

Il professore fa anche un esempio concreto con il metodo sample di Rx, che campiona un flusso ogni 500 millisecondi, poi fa un mapping su stringa e prende gli ultimi 5 elementi. Questo tipo di operatori sono estremamente utili nella pratica per filtrare flussi ad alta frequenza.

Verifica le tue conoscenze