Quali sono le complessità nell'uso della parola chiave volatile nel linguaggio C e quali errori si verificano con un uso scorretto, in particolare nel lavoro con la multithreading e i registri hardware?

Risposta.

La parola chiave volatile informa il compilatore che una variabile può cambiare in modo imprevisto per il compilatore (ad esempio, da hardware, un altro thread o un gestore di interruzioni), e impedisce la memorizzazione nella cache del suo valore o l'ottimizzazione degli accessi ad essa.

Usato per:

• Lavorare con i registri hardware.
• Variabili modificate nei gestori di interruzioni.
• Variabili utilizzate nell'interazione tra thread (ma è importante: volatile non garantisce atomicità o sincronizzazione!).

Esempio di utilizzo:

volatile int flag = 0;

void handler() {
    flag = 1; // gestore di interruzione
}

void loop() {
    while (!flag) {
        // aspetta l'evento
    }
    // ...
}

Senza volatile, il compilatore potrebbe sostituire il ciclo con uno infinito (non leggendo flag dalla memoria), con volatile, la variabile viene letta ogni volta dalla memoria.

---

Domanda insidiosa.

È sufficiente usare volatile per un corretto scambio di informazioni tra thread?

Un errore comune è pensare che volatile garantisca la sincronizzazione della memoria tra thread e renda le operazioni atomiche.

Risposta corretta:

volatile non protegge dagli accessi concorrenti in un ambiente multithread e non fornisce barriere di memoria: essa informa solo il compilatore di non ottimizzare l'accesso. Per una correttezza garantita è necessario utilizzare primitiva di sincronizzazione (mutex, operazioni atomic, ecc.).

// Questo non è sicuro!
volatile int ready = 0;

void thread1() {
    data = 123;   // scrittura dei dati
    ready = 1;    // segnale per un altro thread
}

void thread2() {
    while (!ready); // attesa dell'evento
    printf("data = %d
", data); // potrebbe essere che data non sia ancora aggiornata!
}

---

Storia

---

Nel progetto dei microcontrollori, la variabile per lo scambio tra il ciclo principale e il gestore di interruzioni non era stata definita come volatile, il che causava impedimenti nel firmware: le modifiche al flag non venivano rilevate.

---

In un server multithread è stato usato volatile per lo scambio di segnali, pensando che fosse sufficiente, ma di conseguenza si sono trovati di fronte a bug difficili da individuare: a volte un thread leggeva dati obsoleti o addirittura in uno stato non consistente — era necessaria una variabile atomica o un mutex.

---

Errore nel lavoro con i registri hardware: i valori venivano scritti/letti senza volatile e il compilatore ottimizzava l'accesso, portando a un completo disinteresse per i nuovi valori dei registri — parte dei comandi non funzionava.