Transactional Memory, DNA da super computer nel nuovo #zEnterprise #EC12


I nuovi mezzi di comunicazione, la velocità e la voracità con cui si consumano le informazioni, trasformano una novità in un dato di fatto in 1-2 giorni e dopo in notizia vecchia. Ma di questi argomenti ne parla con più autorevolezza questo blog http://massimochiriatti.nova100.ilsole24ore.com io faccio questi riferimenti perchè cercando in internet notizie da proporvi, inizio a leggere post ed articoli che mi appaiono sempre più simili e mi lasciano il sapore di cose già lette. Le caratteristiche dei nuovi sistemi elencate da tutti (anche qui in un post precedente) si ripetono di sito in sito e io inizio ad avere altre curiosità.

Tra tutte le caratteristiche che ho sentito e letto, la Transactional Memory mi ha colpito. Si perchè, confesso, non avevo idea di cosa fosse; ho solo capito che migliora il parallellismo. Ma perché? Come? Erano domande che in giro per la mia mente non osavano uscire allo scoperto per non fare brutta figura e si sono subito andate a nascondere. Ma svuotando la casella di posta ho letto una segnalazione dal gruppo z/OS Social Forum di una discussione dal titolo zEC12 Transactional Execution (and Memory) di Francesco Andriani che le ha fatte venire nuovamente allo scoperto.

Francesco dice “Una delle più importanti novità del nuovo mainframe, lo zEnterprise EC12, è la cosiddetta Transactional Execution, basata sulla tecnologia Transactional Memory introdotta per la prima volta nel supercomputer BlueGene/Q Sequoia del Lawrence Livermore National Labs.” e condivide una citazione delle zEC12 FAQL’Esecuzione Transazionale fornisce un’approccio alternativo per l’utilizzo dei lock, e dovrebbe, nel tempo permettere l’eliminazione dei lock. […] L’Esecuzione Transazionale è ottimizzata in modo da assumere che non ci sia modifica dei dati all’interno di un singolo thread e se si verifica viene gestita con un modesto overhead, senza necessità di meccanismi di locking. Questa eliminazione fa risparmiare circa 160 istruzioni per ciascun aggiornamento di memoria di tipo transazionale“. Sempre dalle FAQ si legge poi che “l’IBM Java Runtime Environment sfrutterà la Transactional Execution Facility un futuro rilascio di fix […] e che ci si aspeta che anche lo z/OS ed altri compilatori beneficeranno di questa funzionalià.

Bene, grazie Francesco, hai appagato un po’ la mia curiosità! Trovo anche interessante l’articolo citato da Francesco IBM’s new transactional memory: make-or-break time for multithreaded revolution  datato Agosto 2011 dove viene spiegato l’impiego della Transactional Memory nel supercomputer IBM BlueGene/Q.  Qui vengono spiegate bene le differenze tra un’approccio trradizionale con lock ed il meccanismo di Transactional Memory.

Nell’approccio tradizionale, i processi che devono girare simultaneamente e che condividono aree di memoria, per lavorare in modo coordinato utilizano i meccanismi di lock per evitare la sovrapposizione incontrollata delle operazioni di scrittura e lettura della memoria. Quindi per un processo acquisire il lock di memoria significa “metterci il cappello” e far sapere a tutti gli altri che devono aspettare perchè lui la sta modificando. Questo semplice meccanismo è molto efficiente in situazioni dove molti processi leggono spesso e di rado aggiornano i dati di memoria. Ma quando gli aggiornamenti sono frequenti insorgono dei problemi: il più evidente è l’aumento dei tempi di attesa, con una effettiva diminuzione del parallellismo. Poi, nela caso di processi che debbano aggiornare aree differenti esiste sempre il problema del dead-lock; ad esempio se un processo deve aggiornare prima l’area A e poi l’area B inizierà prendendo il lock dell’area A,  ma se allo stesso tempo esiste un proicesso che vuole aggiornare prima l’area B e poi l’area A questo inizierà mettendo il lock sull’area B. Così facendo il secondo processo impedirà al primo di andare avanti ad acquisire il lock dell’area B, quindi il primo si fermerà aspettando che si liberi B. Ma il secondo processo andando avanti cercherà di acquisire il lock dell’area A, che è preso dal primo ora in attesa, quindi anche il secondo si fermerà aspettando che si liberi il lock. Questa condizione dove ciascuno dei due processi è fermo in attesa che l’altro rilasci il lock è il vicolo cieco chiamato dead-lock.

Il mecanismo di memoria transazionale funziona su un principio diametralmente opposto e senza lock. Ciascun processo definisce al suo interno il pezzo di codice che considera at omico, ossia che necessita di certezza nella gestione della memoria (i più sapienti mi passino il termine) e questa porzione di codice è definita come transazione. Quando la transazione viene eseguita compie tutte le sue operazioni senza lock e senza preoccuparsi di come si stia modificando la memoria nel frattempo. All’interno della transazione il processo può leggere la memoria condivisa con altri processi, farci tutte le operazioni che vuole e dopo averla scritta deve fare un’operazione di commit per assicurarsi che venga scritta in modo definitivo. Nel commit c’è la parte intelligente: il meccanismo di memoria transazionale verifica che la porzione di memoria su cui si sta scrivendo non sia stata modificata da altri durante l’esecuzione della transazione. Se non è stata modificata la scrittura diventa definitiva. Se, invece è stata modificata, la transazione viene abortita e dovrà essere eseguita nuovamente.

Questo è un approccio ottimistico: invece di far aspettare tutti per evitare che, se qualcuno volesse scrivere, si creino dei disallineamenti, si preferisce rieseguire il codice della transazione solo nel caso che qualcuno abbia veramente scritto.

Bene ecco quindi una parte di tecnologia utilizzate nei supercomputer che viene innestata resa disponibile nei server EC12 per facilitare il trattamento parallelo di grosse moli di dati.

Annunci

i Quaderni di mainframeitalia: viaggio al centro del #mainframe


Mi capita spesso di fare delle discussioni con colleghi o clienti su alcuni argomenti del mondo del mainframe ed alla fine avere in testa l’idea di scrivere qualcosa di più approfondito ed argomentato sull’argomento. Proprio nel rispondere ad una domanda sollevata da un (giovane) collega mi è venuta l’idea di fare la descrizione di come è fatto un mainframe.
Ecco quindi una delle prime proposte/novità che vorrei portare avanti con mainframeitalia.com: non un libro perché non è alla mia portata, ma un quaderno, che spero, per tempo ed impegno necessari, sia il primo di una serie. Questo descrive come si vede un mainframe e quali sono i pezzi che lo compongono dietro ai suoi sportelli fino ad arrivare al processore utilizzato da questi sistemi.
Potete capire che il lavoro l’ho svolto nei mesi passati e sono stato colto in contropiede dall’annuncio del nuovo EC12; quindi il quaderno utilizza lo z196 per il viaggio, ma alla fine ho aggiunto un capitolo dove descrivo alcune novità dell’EC12: non potevo ignorarlo del tutto!

Potete scaricare il quaderno in formato PDF dal widget di BOX.com qui sulla Sx nel folder i Quaderni e, appena finirà l’iter di approvazione su iBookstore, potrete scaricare una versione, sempre gratuita, con maggior fruibilità delle immagini per i differenti iDevice.