Programmazione asincrona

1. Motivazioni e panorama dei modelli asincroni

La programmazione asincrona è uno stile di programmazione sempre più importante e pervasivo, supportato ormai da tutti i principali framework e piattaforme (Java, .NET, iOS, Android, JavaScript/Node.js). Il suo cuore è la gestione di computazioni, richieste o processi che vengono eseguiti in modo non bloccante, astraendo il più possibile dai thread fisici del sistema operativo.

La programmazione asincrona non si sostituisce ai thread, ma offre un modo diverso di pensare alla concorrenza, spesso più adatto a scenari I/O-bound e reattivi. L'evoluzione storica mostra una ricerca costante di pattern migliori: Microsoft è passata dall'Asynchronous Programming Model (APM) all'Event-based Asynchronous Pattern (EAP) con .NET 2.0, fino al Task-based Asynchronous Pattern (TAP) con .NET 4.5.

In forma tabellare, le quattro grandi famiglie di approcci:

Eventi vs Thread: un dibattito storico

Il professor Ricci cita il dibattito fondamentale tra eventi e thread:

• "Why threads are a bad idea (for most purposes)" — John Ousterhout, USENIX 1996
• "The Problem with Threads" — Edward Lee, IEEE Computer 2006
• "Why events are a bad idea" — von Behren, Condit, Brewer, HotOS 2003
• "Event-driven Programming is Not the Opposite of Threaded Programming" — Adya et al., Microsoft Research, 2002

Questi lavori hanno mostrato come l'approccio event-driven offra vantaggi in termini di assenza di race condition e deadlock a basso livello, mentre i thread rimangono insostituibili per lo sfruttamento del parallelismo hardware. Ogni approccio ha pro e contro: la vera sfida è come metterli insieme.

Un secondo sguardo alle quattro famiglie, con il loro ruolo architetturale:

2. Event-driven programming e l'event loop

Un programma event-driven è fatto di gestori di eventi (event handler) che vengono chiamati (eseguiti, attivati) quando si verificano eventi. Gli eventi possono riferirsi a qualsiasi cambiamento di stato o input dall'ambiente rilevante per il programma: azioni utente (click, pressioni di tasti), output di sensori, messaggi, risposte ricevute. Una caratteristica fondamentale è che il flusso di controllo dipende dagli eventi, introducendo non-determinismo. Si parla anche di "programming without a call stack": dopo l'esecuzione di ogni handler lo stack è vuoto.

Modello di esecuzione: l'event loop

L'event loop è un'architettura di controllo in cui un singolo thread di controllo attende eventi ed esegue gli handler corrispondenti. Una coda degli eventi tiene traccia degli eventi generati dall'ambiente o dagli handler stessi. Gli handler sono eseguiti atomicamente: se un evento si verifica mentre un handler è in esecuzione, sarà servito solo al termine dell'handler corrente (nessuna concorrenza).

loop {
  Event ev = waitForEvent(eventQueue)
  Handler handler = selectHandler(ev)
  execute(handler)
}

flowchart LR
    EQ[("Coda eventi")] --> EL["Event Loop"]
    EL -->|"preleva evento"| H["Handler"]
    H -->|"esegue
atomicamente"| COMP
    COMP -->|"può generare
nuovi eventi"| EQ
  

Schema semplificato del modello event loop: un singolo thread attende eventi, esegue gli handler in modo atomico, e gli handler stessi possono generare nuovi eventi.

Esplorate gli stati dell'Event Loop nel modello astratto:

Il professore sottolinea un punto cruciale: in un modello event loop puro, non ci possono essere race condition. Perché? Perché non c'è condivisione di stato tra thread concorrenti: c'è un solo thread che accede allo stato, in modo sequenziale. Le race condition nascono solo se si introduce un meccanismo come async/await che permette a un blocco di codice di sospendersi e riprendersi, come vedremo più avanti.

L'event loop è il pattern che sta sotto JavaScript, Node.js e — guarda caso — l'event loop incapsulato di ogni attore: un singolo thread attende eventi, li dispatca agli handler appropriati e ogni handler viene eseguito fino al completamento prima di servire l'evento successivo.

3. Il Reactor pattern

Il Reactor pattern (Schmidt et al., Pattern-Oriented Software Architecture Volume 2, 2000) è il pattern architetturale che formalizza l'event loop come pattern di progettazione per sistemi concorrenti e distribuiti. Separa la demultiplazione e la dispatch degli eventi dalla logica applicativa. I partecipanti principali sono:

• Handle — identifica una sorgente di eventi (es. una socket TCP "pronta per la lettura")
• Initiation Dispatcher — demultiplexa gli eventi e dispaccia gli handler appropriati
• Event Handler — specifica i metodi hook per rispondere agli eventi
• Concrete Event Handler — implementazione specifica dell'handler

Il flusso di collaborazione: quando un Handle diventa "pronto", l'Initiation Dispatcher lo rileva, usa l'Handle come chiave per localizzare l'Event Handler appropriato, e chiama il metodo hook corrispondente.

sequenceDiagram
    participant Client as Client
    participant ID as Initiation Dispatcher
    participant EH as Event Handler
    participant CEH as Concrete EH

    Client->>ID: register handle + handler
    Client->>ID: event occurs on handle
    ID->>EH: handle_event(handle)
    EH->>CEH: perform app logic
    CEH-->>EH: result
    EH-->>ID: done
    

4. La regola del never-blocking

Cosa fare quando serve un'operazione che sarebbe bloccante (come leggere un file o fare una richiesta di rete)? La risposta è sostituirla con una richiesta o computazione asincrona, che genererà un evento in futuro (risultato o errore). Queste richieste asincrone sono servite da altri thread (indipendenti dall'event loop), che interagiscono con l'event loop inserendo eventi nella coda.

flowchart LR
      subgraph "Event Loop Thread"
        el[Event Loop] --> h[Handler]
        h --> |delega task bloccante| Pool
        h --> |torna in attesa| el
      end
      subgraph "Background Thread Pool"
        Pool[Worker Pool]
        Pool --> |task completato| coda[(Event Queue)]
      end
      coda --> |evento pronto| el

Multiple event loop

Un sistema può essere composto da più componenti attivi, ciascuno con il proprio event loop privato, la propria coda eventi e i propri task asincroni non bloccanti. In questo caso i componenti:

• non condividono memoria;
• comunicano generando eventi gli uni per gli altri (tipicamente tramite un event bus).

5. Callback e Continuation-Passing Style

Dato il vincolo del non-blocco, come eseguire handler di lunga durata? La risposta è: eseguendo task/funzioni asincrone. L'handler attiva l'esecuzione di un task asincrono e prosegue senza attendere il risultato. Ma sorge il problema centrale: come elaborare i risultati o gli errori generati asincronamente? Attraverso il modello callback.

Una callback è una funzione specificata come argomento (tipicamente l'ultimo) di una chiamata a funzione/task asincrono. La callback viene invocata dall'event loop quando viene processato l'evento relativo al risultato o errore generato dall'esecuzione asincrona. In questo modo la callback definisce una continuazione della computazione, da cui il nome Continuation-Passing Style (CPS).

Il CPS non è nato con la concorrenza: è uno stile di programmazione che può essere applicato anche al codice sequenziale. L'idea è che ogni funzione, invece di restituire un risultato tramite return, prende un argomento extra — la continuazione — e le passa il risultato. In questo modo non serve più uno stack: la computazione diventa una sequenza di chiamate, senza mai tornare indietro.

Ecco come si trasforma una funzione normale in CPS:

Notate che in CPS sum non ha più un tipo di ritorno: restituisce void perché il "risultato" viene passato alla continuazione. Il corpo calcola x + y e poi chiama cont(x + y). Nel caso asincrono, la continuazione viene chiamata non immediatamente, ma quando il risultato dell'operazione asincrona è disponibile.

// CPS in Java (esempio astratto dalle slide)
void sum(int x, int y, Consumer<Integer> cont) {
    cont.accept(x + y);
}
sum(1, 3, (res) -> { System.out.println(res); });

Il professore cita un aneddoto: "Spesso nei colloqui chiedono cosa vuol dire CPS e molti rispondono 'Continuous Passing Style' invece di 'Continuation Passing Style' — ma il senso è lo stesso: passare una funzione che rappresenta la continuazione della computazione."

L'esempio loadUserPic: da sincrono ad asincrono

function loadUserPic(userId) {
  let user = findUserById(userId);
  return loadPic(user.picId);
}

function loadUserPic(userId, ret) {
  findUserById(userId, (user) => {
    loadPic(user.picId, ret);
  });
}
loadUserPic('john', (pic) => {
  ui.show(pic);
});

La stessa trasformazione, riga per riga:

Callback come closure

Le callback sono spesso implementate come closure, una tecnica per il name binding lessicale in linguaggi con funzioni di prima classe.

Un esempio minimale: asyncInc

Il professore fa un esempio concreto in JavaScript, mostrando come una funzione asincrona come asyncInc prenda un valore e una callback, esegua l'incremento nel ciclo successivo dell'event loop (tramite setTimeout(..., 0)) e chiami la callback con il risultato.

Chi invoca la continuazione?

Un aspetto importante è chi invoca la continuazione/callback. Due possibilità:

1. Un thread di controllo diverso da quello che ha attivato la richiesta (es. il thread che genera l'evento) — ma questo introduce potenziali race condition con lo stato condiviso.
2. Nell'architettura event-loop, la continuazione viene eseguita dall'event-loop stesso, ossia dal thread logico che ha attivato il task asincrono (che è diverso dal thread che ha servito il task). Questo è il modello di esecuzione delle moderne app web (client e server) ed evita le race condition perché tutto passa attraverso un unico thread.

Il thread fisico che ha eseguito materialmente il task asincrono (es. una lettura di rete) è diverso, ma la continuazione torna sempre all'event loop — questo è il punto cruciale che evita le race condition.

6. Callback hell e Pyramid of Doom

Con le callback possiamo scrivere codice asincrono, ma la complessità emerge quando dobbiamo coordinare più operazioni. Due pattern fondamentali:

asyncTask1(..., (res1) => {
  asyncTask2(..., (res2) => {
    ...
  })
})

asyncTask1(..., (res1) => { ... })
asyncTask2(..., (res2) => { ... })

Il problema emerge quando si annidano più callback in sequenza: la struttura del codice si espande orizzontalmente e verso destra invece che verticalmente. È la cosiddetta callback hell o pyramid of doom.

step1(function(result1) {
  step2(function(result2) {
    step3(function(result3) {
      // e cosi' via...
    })
  })
})

I problemi principali di questo stile:

1. Asynchronous spaghetti — la computazione complessiva viene frammentata in handler asincroni sparsi e non strutturati, compromettendo la modularità e la struttura del programma.
2. Scarsa leggibilità — il flusso di controllo è difficile da seguire: per capirlo bisogna spostarsi a destra, giù, e poi tornare su.
3. Scarsa riusabilità ed estendibilità — le callback annidate sono strettamente legate al contesto di annidamento, difficili da estrarre e testare.

Un esempio concreto mostrato dal professore è quello del server HTTP in Node.js, dove l'annidamento è ancora più pronunciato. Esploratelo riga per riga:

Il professore cita un commento emblematico di uno sviluppatore sul Google Group di Node.js: "I love async, but I can't code like this." La necessità di un meccanismo migliore era evidente.

7. Promise: stati e API

Le Promise, proposte originariamente nel 1976 da Daniel Friedman e D. Wise, sono la risposta al callback hell. Una Promise è un oggetto proxy che rappresenta un risultato non ancora disponibile ma che sarà calcolato in futuro (simile ai future). Incapsula azioni asincrone, comportandosi come un valore di ritorno di una computazione, anche se il valore potrebbe non essere ancora disponibile.

Proprietà fondamentali

• Una Promise può trovarsi in uno di tre stati: pending (iniziale), resolved/fulfilled (completata con successo) o rejected (completata con errore).
• Una Promise può essere risolta o rigettata una e una sola volta.
• Una volta settled (risolta o rigettata), è immutabile: stato e valore non cambiano più.
• Permette di appiattire l'annidamento delle callback.

Esplora i tre stati con il widget interattivo qui sotto:

L'API fondamentale: myPromise.then(onComplete, onError) dove onComplete è la callback chiamata se/quando la funzione asincrona termina correttamente, e onError (opzionale) è la callback chiamata in caso di errore.

let promisedPic = loadUserPic('john');
promisedPic.then(
  (pic) => { ui.show(pic); },
  (err) => { console.error(err); }
);

Creazione di una Promise

// Creazione di una Promise
let promise = new Promise((resolve, reject) => {
    // fai qualcosa di asincrono...
    if (/* tutto ok */) {
        resolve("Stuff worked!");
    } else {
        reject(Error("It broke"));
    }
});

// Uso con then
promise.then((result) => {
    console.log(result); // "Stuff worked!"
}, (err) => {
    console.log(err); // Error: "It broke"
});

Un esempio più realistico dalle slide, con successo o fallimento casuale:

function delayWithRandom(t, p) {
    let promise = new Promise((resolve, reject) => {
        setTimeout(() => {
            let r = Math.random();
            if (r > p) {
                resolve(r);   // successo
            } else {
                reject(r);    // fallimento
            }
        }, t);
    });
    return promise;
}

let promise = delayWithRandom(1000, 0.5);
promise.then(
    (r) => { console.log("successo:", r); },
    (r) => { console.log("fallimento:", r); }
);

Il costruttore new Promise((resolve, reject) => { ... }) riceve una funzione executor che avvia subito il lavoro asincrono. Le funzioni resolve e reject sono i callback che, quando chiamati, portano la promise nello stato rispettivo. Lo stesso esempio, annotato riga per riga:

Configurazione vs esecuzione

Il professore sottolinea un punto cruciale: quando chiamate promise.then(callback), non state eseguendo nulla. Siete in una fase di configurazione: state dichiarando cosa deve succedere quando l'evento si verifica. È la stessa idea del modello dichiarativo che ritroveremo nella programmazione reattiva.

Promisificazione di codice esistente

Il professore mostra come "promisificare" una chiamata AJAX tradizionale, incapsulando l'API callback-based in una Promise:

function get(url) {
  // Restituisce una nuova Promise
  return new Promise((resolve, reject) => {
    let req = new XMLHttpRequest();
    req.open('GET', url);
    req.onload = () => {
      if (req.status == 200) {
        resolve(req.response);
      } else {
        reject(Error(req.statusText));
      }
    };
    req.onerror = () => {
      reject(Error("Network Error"));
    };
    req.send();
  });
}

// Uso
get('story.json').then(
  (response) => { console.log("Success!", response); },
  (error) => { console.error("Failed!", error); }
);

8. Promise chaining e composizione

La caratteristica che rende le Promise così potenti è che il metodo then restituisce a sua volta una Promise, permettendo di creare catene (chaining) che appiattiscono la pyramid of doom in una sequenza lineare:

let promise = new Promise((resolve, reject) => {
  resolve(1);
});
promise.then((val) => {
  console.log(val); // 1
  return val + 2;
}).then((val) => {
  console.log(val); // 3
});

Il confronto diretto con le callback annidate rende evidente il guadagno:

// Versione con callback annidate
findUserById('john', (user) => {
  findPic(user.picId, (pic) => {
    ui.show(pic);
  });
});

// Stessa logica con Promise chaining
findUserById('john')
  .then((user) => {
    return findPic(user.picId);
  })
  .then((pic) => {
    ui.show(pic);
  });

Il codice diventa lineare e leggibile. Ogni .then() restituisce una nuova Promise, e il valore restituito dalla callback diventa il valore di risoluzione della Promise successiva. In forma compatta, con gestione dell'errore in coda:

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));

Propagazione dei valori

let myProm1 = delayWithRandom(1000, 0.5);
let myProm2 = myProm1.then((v) => {
  console.log(v);
  return "done";
});
myProm2.then((v) => {
  console.log(v); // Stampa "done"
});

Un esempio completo di catena di operazioni asincrone dalle slide:

// Promise chaining: la piramide diventa sequenza
function delayWithRand(t) {
    return new Promise((resolve) => {
        setTimeout(() => { resolve(Math.random()); }, t);
    });
}

let promise = delayWithRand(1000);
promise
    .then((r) => {
        console.log("successo:", r);
        return delayWithRand(1500);
    })
    .then((r) => {
        console.log("successo:", r);
        return delayWithRand(500);
    })
    .then((v) => {
        console.log(v);
    });

Pattern di flusso

Le Promise supportano pattern fondamentali di flusso asincrono:

Il parallelismo si può ottenere anche attaccando più then alla stessa Promise:

let myPromise = asyncFunc1(...);
myPromise.then((v) => { return asyncFunc2(...); });
myPromise.then((v) => { return asyncFunc3(...); });

Nel pattern parallelo, entrambe le callback sono attaccate alla stessa Promise: vengono chiamate entrambe quando asyncFunc1 termina, con lo stesso valore risultato. Le due funzioni asincrone (asyncFunc2 e asyncFunc3) vengono quindi eseguite concorrentemente.

asyncFunc1()
    .then((v) => {
        console.log(v);
        return asyncFunc2();
    })
    .then((v) => {
        console.log(v);
        return asyncFunc3();
    })
    .then(...);

let p1 = delayWithRand(1000);
let p2 = delayWithRand(2000);
Promise.all([p1, p2]).then((values) => {
    console.log(values[0]);
    console.log(values[1]);
});

let p1 = delayWithRand(1000);
let p2 = delayWithRand(2000);
Promise.race([p1, p2]).then((value) => {
    console.log(value);
});

Promise.all e Promise.race in dettaglio

// Promise.all - join point per task paralleli
let myProm1 = delayWithRand(1000);
let myProm2 = delayWithRand(2000);
let myTotalProm = Promise.all([myProm1, myProm2]);
myTotalProm.then((values) => {
  console.log(values[0]); // risultato del primo
  console.log(values[1]); // risultato del secondo
});

// Promise.race - chi arriva prima
let myProm3 = delayWithRand(1000);
let myProm4 = delayWithRand(2000);
let myRaceProm = Promise.race([myProm3, myProm4]);
myRaceProm.then((value) => {
  console.log(value); // risultato del piu' veloce
});

Gestione degli errori

Le Promise migliorano significativamente la gestione degli errori rispetto alle callback pure. Le regole sono chiare:

• Ogni handler che restituisce un valore e non lancia eccezioni propaga il successo alla Promise successiva.
• Ogni handler che lancia un'eccezione propaga un reject alla Promise successiva.
• Uno stato non gestito viene passato alla Promise successiva nella catena finché non trova un handler di errore.
• Una volta che l'errore ha trovato un handler, l'elaborazione normale riprende nella catena.

asyncTask()
  .then((result) => { return transform(result); })
  .catch((err) => { console.error("Errore:", err); })
  .then((final) => { console.log("OK:", final); });

Visualizza il flusso di una catena con lo stepper:

9. Limiti delle Promise

Nonostante i vantaggi, le Promise presentano alcuni limiti significativi che il professore analizza nel dettaglio.

Eagerness e il parametro di then

Considerate questo codice apparentemente corretto ma in realtà sbagliato:

printTime();
delay(1000)
  .then(printTime)
  .then(delay(1000))   // PROBLEMA!
  .then(printTime);

Il problema è che delay(1000) viene invocato immediatamente, non passato come funzione da chiamare. Il risultato corretto è:

printTime();
delay(1000)
  .then(printTime)
  .then(() => { return delay(1000); })
  .then(printTime);

Impossibilità di usare loop/iterazioni

for (let i = 0; i < 3; i++){
  delay(1000).then(() => {
    let time = new Date().getTime();
    console.log(i + " > " + time);
  })
}
// NON funziona come previsto: tutte e tre partono concorrentemente!

Con un for classico, tutte le Promise vengono create nello stesso ciclo dell'event loop: partono quindi concorrentemente, non in sequenza. Il professore usa un esempio concreto: quando chiamate delay(1000) in un for, create 10 Promise che partono tutte nello stesso momento (stesso "ciclo" dell'event loop). Se volevate aspettare 1 secondo tra una stampa e l'altra, il risultato è sbagliato: tutte le stampe arrivano dopo un secondo, non ogni secondo per dieci secondi.

Per ottenere una sequenza con le Promise, serve la ricorsione:

function sequenza(indice) {
  if (indice >= 3) return;
  delay(1000).then(() => {
    console.log(new Date().getTime());
    sequenza(indice + 1);
  });
}

Il professore commenta: "Se interpreti l'aspetto funzionale in modo puro, non hai bisogno del for. Ma per dirvi come si complica."

Cancellazione

Le Promise non possono essere cancellate. Una volta avviato un task asincrono tramite Promise, non c'è modo di fermarlo. In alcuni scenari questo può portare a spreco di risorse.

10. Async/await

L'estensione linguistica async/await è la soluzione più recente e promettente nella programmazione asincrona. Introdotta in ES2017 (8ª edizione dello standard ECMAScript, giugno 2017), è implementata in .NET TAP (C#), Python, Dart, Kotlin e molti altri linguaggi. L'obiettivo è fornire uno stile di programmazione sincrono mantenendo un core asincrono: il codice asincrono appare e si comporta come codice sincrono, ma senza blocco.

L'idea fondamentale:

// Stile async con Promise
let p = asyncFunc(...);
p.then(onCompleteFunc, onErrorFunc)

// Stile async/await - sembra sincrono ma e' asincrono
let res = await asyncFunc(...);
// usa res -> qui arrivo solo quando la Promise e' risolta

L'operatore await si applica a qualsiasi Promise e sospende l'esecuzione della funzione finché la Promise non è risolta, ma non blocca il thread di controllo: il controllo viene ceduto (yield), salvando lo stato corrente della computazione. await converte una Promise in un risultato o un'eccezione, esattamente come se fosse il risultato di una funzione sincrona.

Regole fondamentali

• await si può usare solo dentro funzioni marcate async.
• Una funzione async restituisce sempre una Promise, anche se non contiene await.
• Il async serve a delimitare il blocco che può essere sospeso.
• C'è propagazione di async/await: se una funzione chiama await, deve essere async, e chi la chiama con await deve essere async, e così via.

var myFunc = async function() {
  console.log("here1");
  await delay(3000);
  console.log("here2");
  await delay(2000);
  console.log("here3");
  return 1 + 2;
};

Una funzione async è una funzione sospendibile che restituisce una Promise. Il corpo viene convertito in un oggetto AsyncFunction che contiene il macchinario di basso livello (basato su coroutine) per esprimere il corpo usando uno stile sincrono.

console.log("pre");
console.log(myFunc);      // [AsyncFunction]
console.log(myFunc());    // Promise {}
console.log("post");
// Output:
// pre
// [AsyncFunction]
// Promise {}
// post

Segui l'esecuzione riga per riga con l'annotated code:

Funzioni async con e senza await

Il professore mostra una differenza importante: chiamare una funzione async con o senza await produce comportamenti diversi.

async function pause(t) {
    console.log("before");
    let promise = new Promise((resolve) => {
        setTimeout(() => { resolve(); }, t);
    });
    await promise;
    console.log("after"); // eseguito dopo il timer
}
console.log("before call");
pause(1000); // <-- senza await qui
console.log("after call");
// Output: before call, before, after call, after

async function main() {
    console.log("before call");
    await pause(1000); // <-- con await qui
    console.log("after call");
}
main();
// Output: before call, before, after, after call

Benefici

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

L'esempio del ciclo, annotato riga per riga:

Simula l'esecuzione sequenziale del ciclo con lo stepper:

Problemi ancora aperti

Modularità e incapsulamento

Un problema ulteriore è di modularità/incapsulamento: una funzione async chiamata senza await produce un comportamento diverso, e il chiamante deve sapere se la funzione è asincrona o meno — un buco nell'incapsulamento. Un esempio discusso dal professore mostra come sia facile sbagliare se non si rispetta la "catena" async:

// Questo NON funziona come ci si aspetterebbe
function g() {
  console.log("started g");
  f(); // f e' async, ma g non la awaita
  console.log("done g");
}

// Versione corretta
async function g() {
  console.log("started g");
  await f();
  console.log("done g");
}

Il design clash

Un aspetto critico sottolineato dal professore è il design clash tra stile sincrono e asincrono: serve una forte disciplina nel mescolare i due stili per evitare programmi con comportamento difficile da comprendere. C'è bisogno di astrazioni di livello più alto che integrino naturalmente prospettiva sincrona e asincrona — è qui che si inserisce la programmazione reattiva.

11. Coroutine e fiber

Sia async/await che i thread leggeri condividono un meccanismo di base: le coroutine. Le coroutine sono una generalizzazione del concetto di subroutine che permette all'esecuzione di essere sospesa e ripresa (Conway, 1963, per la compilazione di diagrammi di transizione). Mentre una subroutine tradizionale ha un solo punto di ingresso e un solo punto di uscita (il return), una coroutine può avere più punti di sospensione (yield o await) e può essere ripresa dal punto in cui si era fermata, senza perdere lo stato locale.

Storicamente le coroutine sono nate nei linguaggi assembly, poi in Simula, Smalltalk, Modula-2. Recentemente hanno ricevuto rinnovata attenzione proprio grazie alla programmazione asincrona (Ruby, Lua, Julia, Go, Kotlin). Non sono legate agli eventi o alla programmazione event-driven: sono un meccanismo più fondamentale di controllo del flusso.

flowchart TB
    subgraph Subroutine
        A1["call X()"] --> A2["esegui corpo"]
        A2 --> A3["return al chiamante"]
    end
    subgraph Coroutine
        B1["call coroutine()"] --> B2["esegui fino a yield"]
        B2 -->|"yield"| B3["sospendi e cedi controllo"]
        B3 -->|"resume"| B4["riprendi dal punto di sospensione"]
        B4 --> B2
    end
  

Differenza tra subroutine (in alto) e coroutine (in basso): la subroutine torna sempre al chiamante, mentre la coroutine può sospendersi e riprendere l'esecuzione dal punto in cui si era fermata.

Caratteristiche principali

• Una coroutine mantiene lo stato tra un'invocazione e l'altra.
• Possono esistere più istanze della stessa coroutine simultaneamente.
• Non si basano su eventi o event-driven programming: sono un meccanismo più fondamentale di controllo del flusso.
• Le subroutine tradizionali sono un caso speciale di coroutine che non chiamano mai yield.

Esempio classico: sistema produttore-consumatore cooperativo a singolo flusso, dove produce e consume si alternano tramite yield.

// Esempio: producer-consumer cooperativo con coroutine
var q := new queue

coroutine produce
  loop
    while q is not full
      create some new items
      add the items to q
    yield to consume

coroutine consume
  loop
    while q is not empty
      remove some items from q
      use the items
    yield to produce

flowchart LR
      subgraph "Coroutine Producer"
        P1[crea item] --> P2[yield to Consumer]
        P2 --> P1
      end
      subgraph "Coroutine Consumer"
        C1[prende item] --> C2[yield to Producer]
        C2 --> C1
      end

Modello di concorrenza basato su coroutine

Le coroutine possono essere usate come meccanismo di basso livello per implementare thread leggeri (lightweight threads): un thread può avere molte coroutine al suo interno, ma solo una coroutine è in esecuzione in un dato momento. Sono veloci ed economiche da creare e gestire, non richiedendo context switching da parte del sistema operativo.

Coroutine in Kotlin

Kotlin è un esempio moderno di linguaggio con supporto nativo alle coroutine. Concetti principali:

Esempio Kotlin discusso a lezione:

import kotlinx.coroutines.*

fun main(args: Array<String>) = runBlocking {
    println("before async call")
    val result = async {
        println("inside the async call")
        delay(1000)
        println("exiting the async call")
        100
    }
    println("after the async call, before greet")
    greetDelayed(200)
    println("after greet trigger")
    println("${result.await()}")
}

suspend fun greetDelayed(delayMillis: Long) {
    delay(delayMillis)
    println("Hello, World!")
}

L'output mostra l'alternanza tra le due coroutine:

before async call
after the async call, before greet
inside the async call
Hello, World!
after greet trigger
exiting the async call
100

La funzione greetDelayed è marcata come suspend: può sospendersi senza bloccare il thread, permettendo al thread di essere usato per altre computazioni. Il delay è una funzione suspending che sospende l'esecuzione senza bloccare il thread sottostante.

Fiber (fibre)

Una fiber (fibra) è un thread leggero di esecuzione. Come i thread, condivide lo spazio di indirizzi; a differenza dei thread, usa la cooperazione invece del preemptive multitasking. Le fibre possono essere implementate usando un singolo thread. Implementate da UNIX/PThreads, Windows/.NET e, più recentemente, dai Virtual Threads di Java (da JDK 19).

12. Platform thread e virtual thread in Java

Il docente introduce un tema importante per la programmazione concorrente moderna in Java: la differenza tra thread tradizionali e virtual thread, introdotti come feature preview nelle versioni recenti di Java (Project Loom) e stabili da JDK 21. I Virtual Thread rappresentano il tentativo di Java di portare le fiber nel mondo mainstream, mantenendo la compatibilità con l'API java.lang.Thread esistente.

Il docente sottolinea che questa distinzione permette di usare un approccio orientato al problema e al dominio, senza dover ottimizzare manualmente il numero di thread in base all'hardware sottostante.

Mounting e unmounting

L'idea è quella di disaccoppiare il thread logico (il "filo" di esecuzione) dal thread fisico del sistema operativo. I virtual thread sono gestiti interamente dalla JVM, che li monta e smonta sui thread fisici (detto mounting/unmounting) in modo trasparente. Quando un virtual thread esegue un'operazione bloccante (es. I/O, wait(), join()), la JVM lo sospende e riutilizza il thread fisico per un altro virtual thread.

// Creazione di un Virtual Thread (esempio dalle slide del Lab)
Thread.ofVirtual()
    .name("my-virtual-thread")
    .start(() -> {
        System.out.println("Ciao da un virtual thread!");
    });

// Creare 100.000 virtual thread e' possibile e leggero
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100_000; i++) {
        executor.submit(() -> {
            // computazione leggera
        });
    }
}

Dal punto di vista architetturale, i virtual thread non forniscono un trattamento first-class per eventi e computazioni reattive — questo è il punto del dibattito tuttora aperto tra virtual thread e async programming (Brian Goetz, 2022). I virtual thread risolvono il problema del costo dei thread, ma non offrono un modello per gestire eventi e reattività.

Verifica le tue conoscenze