2012-06-29 10 views
7

Sono confuso perché dalla lettura della pagina wiki sembra che abbia solo un sistema di verifica e validazione per carichi e negozi. Lo scopo è risolvere i problemi di sincronizzazione? È una cosa di programmazione software costruita sopra l'hardware corrente o è un'implementazione hardware tramite un ISA? Qual è la differenza tra ciascuna implementazione (HW/SW)?Che cos'è la memoria transazionale?

Grazie.

risposta

3

A livello di implementazione, la memoria transazionale fa parte del livello di cache. Permette al software di "provare" alcune operazioni sulla memoria e quindi "eseguirle" successivamente solo se nessun altro multiprocessore nel sistema ha modificato la memoria che è stata letta o scritta. In ambienti SMP molto paralleli in cui la maggior parte degli accessi non si scontrano, questo può essere più veloce di tutti i thread che bloccano le stesse primitive di sincronizzazione (molto contesa).

Rende più difficile l'attività del programmatore dell'applicazione, poiché il software deve essere in grado di ripristinare ("rollback") la transazione se il commit non riesce.

3

dalla memoria transazionale gcc Wiki:

In general, implementations come in two forms: a Software Transactional Memory 
(STM) system uses locks or other standard atomic instructions to do its job. 
A Hardware Transactional Memory (HTM) system uses multi-word synchronization 
operations of the CPU to implement the requirements of the transaction directly 
(e.g., see the Rock processor). Because most HTM systems are likely to be best 
effort facilities (i.e., not all transactions can be executed using HTM), 
practical TM implementations that incorporate HTM also have a STM component 
and are thus termed Hybrid Transactional Memory systems.

23

è il concetto di utilizzare operazioni piuttosto che serrature per sincronizzare i processi che vengono eseguiti in parallelo e condividere la memoria.

Ad un livello molto semplificata, per la sincronizzazione con serrature a identificare sezioni di codice (chiamato sezioni critiche) che non devono essere eseguiti contemporaneamente da diversi fili e acquisiscono e rilasciare i blocchi intorno alle sezioni critiche. Poiché ogni blocco può essere trattenuto solo da un thread alla volta, ciò garantisce che una volta che un thread entra in una sezione critica, tutte le operazioni della sezione saranno completate prima che un altro thread entri in una sezione critica protetta dallo stesso blocco.

La memoria transazionale consente invece di designare sezioni di codice come transazioni. Il sistema di memoria transazionale (che può essere implementato in hardware, software o entrambi) tenta quindi di darti la garanzia che qualsiasi esecuzione di un programma in cui più thread eseguono transazioni in parallelo sarà equivalente a una diversa esecuzione del programma in cui le transazioni tutte eseguite una dopo l'altra, mai nello stesso momento.

Il sistema di memoria transazionale esegue questa operazione consentendo l'esecuzione delle transazioni in parallelo e monitorando il loro accesso alle variabili di transazione . Se il sistema rileva un conflitto tra l'accesso di due transazioni alla stessa variabile, ne causerà l'interruzione e il "rollback" all'inizio della transazione in esecuzione; riavvierà automaticamente la transazione e lo stato generale del sistema sarà come se non avesse mai avviato la corsa precedente.


Un obiettivo della memoria transazionale è la facilità di programmazione e la sicurezza; un sistema TM correttamente implementato che è in grado di far rispettare correttamente le transazioni dà duro garanzie che non ci sono problemi di parallelismo (deadlock, condizioni di gara, ecc.) nel programma e richiede solo che il programmatore designi le transazioni (e talvolta variabili di transazione, se il sistema non considera solo tutta la memoria come implicitamente variabili di transazione), senza dover identificare esattamente quali blocchi sono necessari, acquisirli nell'ordine corretto per evitare deadlock, ecc, ecc."Transacitons vengono utilizzati correttamente" implica che non ci sono dati di condivisione tra i thread senza passare attraverso le variabili di transazione, nessun accesso ai dati transazionali tranne che nelle transazioni e nessuna operazione "non rollbackable" all'interno delle transazioni); i sistemi di memoria transazionale basati su software di libreria per linguaggi imperativi come C, Java, ecc in genere non sono in grado di far rispettare tutto ciò, il che può reintrodurre la possibilità di alcuni dei bug del parallelismo.

Un altro obiettivo della memoria transazionale sta aumentando il parallelismo; se hai un sacco di operazioni parallele che accedono ad alcune strutture dati, tutte le quali potrebbero scrivere ma poche di esse effettivamente lo fanno, quindi la sincronizzazione basata su lock in genere richiede che tutte le operazioni vengano eseguite in serie per evitare la possibilità di corruzione dei dati. La memoria transazionale consentirebbe a quasi tutte le operazioni di funzionare in parallelo, perdendo il parallelismo solo quando alcuni processi in realtà eseguono nella struttura dati.

In pratica (a partire da quando ho studiato il mio progetto di onorificenza alcuni anni fa), la memoria transazionale basata su hardware non è davvero decollata e gli attuali sistemi di memoria transazionale software hanno significativi costi generali. Pertanto, la memoria transazionale del software è più mirata a "prestazioni ragionevoli che si adattino moderatamente ai processori disponibili ed è piuttosto facile da codificare", piuttosto che offrire prestazioni massime assolute.

C'è molta variabilità tra diversi sistemi di memoria transazionale però; Sto parlando a un livello abbastanza astratto e semplificato qui.

+1

Penso che tu sia overselling qui. Gli algoritmi TM sono sottili, proprio come le tradizionali tecniche di sincronizzazione. E i bug risultanti possono essere ugualmente imperscrutabili. In ogni caso, in genere, è necessaria una variante tradizionale di lavoro come ripiego per le collisioni tra le transazioni, quindi non c'è il pranzo gratis. STM ha ampiamente mancato di attecchire per questi motivi. HTM in Haswell sembra promettente, ma più da un punto di vista delle prestazioni che da una facilità di programmazione. –

+0

** Se ** il sistema STM mira a fornire solide garanzie di sicurezza ** e ** esiste un meccanismo per imporre che (a) i dati condivisi a livello transazionale sono accessibili solo all'interno delle transazioni (b) le transazioni non hanno mai effetti collaterali, quindi I programmi STM sono garantiti senza condizioni di gara e deadlock. Avendo lavorato su implementazioni STM, questo è vero. Lo scarso utilizzo di un tale sistema STM può darti prestazioni pessime a causa della contesa, ma non può darti deadlock o condizioni di gara che causano solo problemi in condizioni di cronometraggio estremamente precise. – Ben

+0

Queste precondizioni non sono vere per le implementazioni STM basate su libreria per C, anche se senza l'integrazione del linguaggio non è possibile applicare (a) e (b), e con C è abbastanza difficile far rispettare comunque. Non so molto di HTM, ma la mia comprensione è che richiedi nuovamente l'integrazione linguistica per garantire la sicurezza, quindi usare HTM da C o assemblatore non viene fornito con il pranzo gratis, no. – Ben

Problemi correlati