La piattaforma Java supporta la programmazione concorrente tramite il concetto di thread di esecuzione. Una applicazione Java può avere più flussi di esecuzione paralleli, ciascuno rappresentato da un oggetto java.lang.Thread.
 |
| Thread di esecuzione - Immagine recuperata da Internet |
Quando due thread hanno necessità di interagire tra loro devono "sincronizzarsi" in modo da evitare situazioni non deterministiche (in cui il risultato varia da un'esecuzione all'altra a causa di variazioni, anche piccole, nei tempi di esecuzione dei singoli step elaborativi). Ed è proprio la sincronizzazione uno degli aspetti più complessi della programmazione concorrente.
La sincronizzazione è caratterizzata da due aspetti in un certo senso ortogonali tra loro:
- mutua esclusione
- visibilità
La mutua esclusione è utilizzata per evitare l'accesso concorrente a strutture dati condivise. La mutua esclusione in Java si basa sul concetto di monitor. Ad ogni oggetto Java è associato un monitor che offre le classiche primitive di lock e unlock. Il runtime garantisce che un solo thread per volta può ottenere il lock su uno stesso monitor. Utilizzando un monitor è possibile impedire l'accesso concorrente a una struttura dati condivisa.
Java mette a disposizione, oltre alle primitive di basso livello sul monitor, anche altri costrutti di sincronizzazione quali i metodi e i blocchi "synchronized" e l'intero package java.util.concurrent. Queste feature non essendo oggetto di questo articolo non saranno però illustrate ulteriormente (magari potremmo ritornarci in futuro, se interessa).
Java mette a disposizione, oltre alle primitive di basso livello sul monitor, anche altri costrutti di sincronizzazione quali i metodi e i blocchi "synchronized" e l'intero package java.util.concurrent. Queste feature non essendo oggetto di questo articolo non saranno però illustrate ulteriormente (magari potremmo ritornarci in futuro, se interessa).
La visibilità è invece un aspetto po' più subdolo. Esso riguarda la capacità di vedere il valore corrente di una varibile da parte dei thread differenti rispetto a quello che ha modificato la variabile (sembra complicato ma leggendo di seguito dovrebbe risultare più chiaro).
Per motivi di prestazioni, la piattaforma Java può conservare in una cache locale a ciascun thread (o in registri della CPU) il valore delle variabili anche quando queste sono condivise tra più thread. Se il valore di una variabile è modificato in un thread, nella cache di tutti gli altri thread potrebbero esserci valori non più aggiornati. Il programmatore deve quindi sempre usare meccanismi di controllo della visibilità per assicurarsi che i thread vedano i valori corretti delle varibili quando accedono a dati condivisi.
La visibilità tra thread è sicuramente garantita usando le primitive di lock/unlock di un monitor (quelle usate per gestire la mutua esclusione). Nella seguente figura sono mostrati i due thread A e B sincronizzati tramite il monitor M. Il modello di memoria Java garantisce che i valori delle variabili disponibili nel thread A, immediatamente prima dell'unlock di M, siano visibili al thread B, subito dopo che questo ha ottenuto il lock di M.
La visibilità tra thread è sicuramente garantita usando le primitive di lock/unlock di un monitor (quelle usate per gestire la mutua esclusione). Nella seguente figura sono mostrati i due thread A e B sincronizzati tramite il monitor M. Il modello di memoria Java garantisce che i valori delle variabili disponibili nel thread A, immediatamente prima dell'unlock di M, siano visibili al thread B, subito dopo che questo ha ottenuto il lock di M.
 |
| Figura dal sito IBM |
Esiste tuttavia anche un modo diverso per forzare la visibilità di una variabile condivisa e che non richiede l'utilizzo di primitive di lock/unlock: il modificatore volatile. Tale modificatore può essere utilizzato per informare la piattaforma che una variabile è acceduta da più thread e si intende garantire la visibilità del valore corrente della variabile (senza bloccare i thread quindi con un miglioramento delle prestazioni dell'applicazione).
Un esempio classico di utilizzo di questo costrutto è il seguente: supponiamo di avere un thread che effettua un lavoro in background finché non gli viene segnalato di terminare. La richiesta di terminazione può essere registrata in una variabile shutdownRequested di tipo boolean che, in generale, sarà impostata da un differente thread.
In questo scenario non vi è un conflitto tra i due thread (perché il thread che lavora in background accede alla variabile shutdownRequested in sola lettura) e non è pertanto necessario usare un monitor per proteggere la risorsa condivisa. Tuttavia il modello di memoria di Java richiede che, per garantire la visibilità del valore della variabile condivisa tra i due thread, sia comunque utilizzato un costrutto di sincronizzazione. In questo caso in cui un monitor sarebbe eccessivo... si può ricorrere al modificatore volatile. Di seguito è riportato il frammento di codice.
In questo scenario non vi è un conflitto tra i due thread (perché il thread che lavora in background accede alla variabile shutdownRequested in sola lettura) e non è pertanto necessario usare un monitor per proteggere la risorsa condivisa. Tuttavia il modello di memoria di Java richiede che, per garantire la visibilità del valore della variabile condivisa tra i due thread, sia comunque utilizzato un costrutto di sincronizzazione. In questo caso in cui un monitor sarebbe eccessivo... si può ricorrere al modificatore volatile. Di seguito è riportato il frammento di codice.
volatile boolean shutdownRequested;
...
public void shutdown() {
...
public void shutdown() {
shutdownRequested = true;
}public void doSomeWork() {
while (!shutdownRequested) {
// ciclo thread1
}
}
Cosa accade se "dimentichiamo" il modificatore volatile? Magari su alcune implementazioni della piattaforma Java il programma continuerà a funzionare correttamente... tuttavia in altre implementazioni (in particolare quelle dedicate a sistemi multiprocessore) l'esecuzione del programma potrebbe far andare il thread di background in un loop infinito: il valore true della variabile shutdownRequest (impostato da un altro thread) non sarebbe visibile al thread di background che continuerebbe a ciclare sul valore iniziale false memorizzato nella propria cache!
Chi volesse approfondire... sul sito Oracle, al link indicato di seguito, sono pubblicate le specifiche della JVM con un capitolo dedicato al modello di memoria di Java (link: Threads e Locks). Un testo specifico sulla programmazione concorrente è Java Concurrency in Practice.
