Ciao, e benvenuto nella sesta puntata della sessantatreesima stagione. Nella puntata scorsa abbiamo visto il mostro: due attività che si intrecciano su un dato condiviso e producono risultati sbagliati. Oggi vediamo la prima grande famiglia di soluzioni, la più antica e la più diffusa: mettere ordine, imporre che a quel dato si acceda uno alla volta. Ma scopriremo anche che questa cura ha i suoi effetti collaterali. Oggi parliamo di uno alla volta, e dei suoi pericoli.
Partiamo dall'idea di base, perché è semplice e potente. Se il problema è che due attività toccano lo stesso dato nello stesso momento, la soluzione più ovvia è: impediamo che accada. Facciamo in modo che, quando un'attività sta usando il dato condiviso, tutte le altre debbano aspettare il loro turno. Solo una alla volta può entrare nella zona delicata, quella in cui si legge e si scrive il dato condiviso. Le altre restano fuori dalla porta, in fila, finché la prima non ha finito ed esce. Questo garantisce che nessuno si pesti i piedi: le operazioni sul dato tornano a succedere in fila, ordinate, come devono.
Voglio darti l'immagine che rende chiara questa idea, perché la fissa. Pensa a un bagno pubblico con una sola porta e una chiave. Chi entra prende la chiave e chiude a chiave dietro di sé. Chiunque altro arrivi trova la porta chiusa e aspetta fuori. Quando chi è dentro esce, lascia la chiave a chi è in fila, e così via, uno per volta. Nessuno si ritrova dentro insieme a un altro. Quella chiave è esattamente lo strumento che usiamo nel codice: un lucchetto che protegge il dato condiviso. Chi vuole toccarlo deve prima prendere il lucchetto; se ce l'ha un altro, aspetta. Semplice, ordinato, sicuro.
Voglio dirti subito il primo effetto collaterale, perché è profondo. Ma c'è un prezzo, e lo conosciamo già dalla stagione scorsa. Ogni volta che imponi uno alla volta, stai creando un tratto in cui il parallelismo scompare. Mentre un'attività tiene il lucchetto, tutte le altre, per quanti cervelli di calcolo tu abbia, stanno ferme ad aspettare. Quel tratto protetto è, di fatto, una porzione seriale del tuo programma: proprio quella parte in fila che, come abbiamo visto, mette un tetto alla velocità. Più metti lucchetti, più larghe fai le zone protette, più trasformi il tuo bel programma parallelo in una processione ordinata ma lenta, dove tutti aspettano il loro turno alla stessa porta.
Voglio darti il secondo effetto collaterale, perché è il più insidioso. E poi c'è un pericolo peggiore, quasi comico se non fosse tragico: il blocco reciproco. Immagina due attività, e due dati protetti da due lucchetti diversi. La prima attività prende il primo lucchetto e poi vuole anche il secondo. La seconda attività, nello stesso momento, ha preso il secondo lucchetto e vuole anche il primo. Ora sono incastrate: la prima aspetta il secondo lucchetto, che è in mano alla seconda; la seconda aspetta il primo lucchetto, che è in mano alla prima. Nessuna delle due mollerà mai, perché ognuna aspetta l'altra. Restano bloccate per sempre, in un abbraccio mortale. Il programma si ferma, senza un errore, senza uno schianto: semplicemente, non va più avanti.
Voglio darti la lezione pratica su questi strumenti, perché serve equilibrio. La lezione è che i lucchetti sono necessari, ma vanno usati con parsimonia e disciplina. Ogni lucchetto è un piccolo pezzo di serialità che sacrifichi, e ogni lucchetto in più aumenta il rischio di abbracci mortali. I bravi programmatori tengono le zone protette il più piccole e brevi possibile, proteggono solo lo stretto necessario, e seguono regole ferree, come prendere sempre i lucchetti nello stesso ordine, per non incastrarsi mai. Il lucchetto è uno strumento potente, ma è come il sale: indispensabile in piccole dosi, rovinoso in eccesso.
Voglio darti la lezione generale, perché va oltre il codice. La lezione è che imporre ordine ha sempre un costo. Ogni volta che, per sicurezza, obblighi le cose a mettersi in fila, guadagni correttezza ma perdi fluidità, e introduci il rischio di ingorghi. Vale per il traffico, per la burocrazia, per qualunque sistema in cui, per evitare il caos, si costringe tutti a passare da un unico punto controllato. La sfida, sempre, è mettere solo l'ordine strettamente necessario, e non un grammo di più. Troppo poco, e regna il caos; troppo, e tutto si impantana.
Per oggi ci fermiamo qui. Abbiamo visto la prima grande cura: uno alla volta. Se due attività si pestano i piedi sul dato condiviso, imponiamo che solo una per volta entri nella zona delicata, con un lucchetto: come la chiave di un bagno con una sola porta. Funziona, ma ha due prezzi. Primo: ogni zona protetta è un tratto seriale, che toglie parallelismo e mette un tetto alla velocità. Secondo: due attività che aspettano a vicenda i lucchetti dell'altra restano bloccate per sempre, in un abbraccio mortale. Perciò i lucchetti vanno usati con parsimonia: zone piccole, brevi, e sempre lo stesso ordine. La lezione: imporre ordine ha sempre un costo. Nella prossima puntata: non condividere, comunica, l'altra filosofia. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.