"STM"

Inizio con questo post una serie di scritti riguardanti la tecnologia “Software Transactional Memory”. Iniziamo quindi con una descrizione molto “alla larga” che con i prossimi scritti raffinerò.
Come direbbe Simon Peyton-Jones, l'idea di STM non è nuova, ma è una architettura che i “DataBase people” conoscono ed usano già da un sacco di tempo. Infatti il modello transazionale è ben conosciuto nel mondo dei DataBase con le ben conosciute “Begin”, “Commit”, ecc.
Facciamo un esempio. Generalmente, un'azione “act” (che può essere una funzione generica) quando eseguita fa passare lo stato del sistema da stato_1 a stato_2. Nel mondo reale può succedere però che una singola azione sia formata da più sotto-azioni più semplici:

act() {subact_1; subact_2; subact_3; subact_n;}

Cosa succede ora se, ad esempio, subact_3 origina un'eccezione che costringe ad uscire da act()? Succede che lo stato del sistema non è più nello stato stato_1, ma neppure nello stato_2 perché act è terminata prima di portare a termine tutti i suoi compiti pur avendo già eseguito subact_1 e subact_2. In questo caso, abbiamo quindi un sistema che si troverà in uno stato incoerente. Qui entra in gioco la tecnologia STM. Consideriamo ora questo frammento di codice:

act = atomically ( do subact_1 subact_2 subact_3 ... subact_n)

Qui creiamo una transazione attraverso l'applicazione della “funzione” atomically(...). Il sistema si accorgerà del cambio dello stato dovuto alla sequenza di tutte le sotto azioni solo dopo che la “commit” è raggiunta (all'uscita dalla chiamata “atomically”). Se ora, come prima, subact_3 genera la solita eccezione, all'interno della transazione, si ha una rollback e quindi lo stato del sistema continua a rimanere coerente (stato_1).
Vedremo in prossimi post come l'STM diventa la tecnologia chiave nell'evoluzione della programmazione multi-threading.

Luca Ciciriello.