Quando più thread condividono dati, le loro operazioni possono intercalarsi (interleave) nel mezzo di un aggiornamento a più passi, producendo una race condition — un bug in cui il risultato dipende da un timing imprevedibile. La sincronizzazione è l'insieme di strumenti che impongono un ordinamento sicuro.
sembra atomico ma in realtà è read-modify-write:
count++// two threads, shared int count = 0, each does count++ once
// thread A: read count (0) ─┐ interleaving loses an update:
// thread B: read count (0) ─┤ both read 0, both write 1 → count == 1, not 2
// thread A: write 1 │
// thread B: write 1 ┘
La finestra tra la lettura e la scrittura è una critical section (sezione critica) — codice che tocca stato condiviso e non deve essere eseguito in concorrenza.
pthread_mutex_lock(&m);
count++; // sezione critica — esclusiva
pthread_mutex_unlock(&m);
I lock risolvono le race ma introducono nuovi rischi: deadlock (thread in attesa dei lock l'uno dell'altro), priority inversion e contention (i thread si serializzano, uccidendo il parallelismo). La regola pratica: mantieni le sezioni critiche brevi, e acquisisci sempre più lock in un ordine globale coerente.
I bug di concorrenza sono tra i più difficili da trovare — sono non deterministici e spesso svaniscono sotto un debugger. Gli intervistatori vogliono vedere che sai individuare una sezione critica, scegliere la primitiva giusta (mutex vs semaforo vs atomica) e ragionare sui modi di fallimento (deadlock, contention). Questo si applica direttamente a qualsiasi server multithread, cache condivisa o contatore.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona