Volatile e Thread.MemoryBarrier in C#

Question

per implementare un serratura di codice libero per il multithreading applicazione che ho usato volatile variabili, Teoricamente: Il volatile parola chiave viene utilizzata semplicemente per fare in modo che tutte le discussioni vedono il valore più aggiornata di un variabile volatile; quindi se il thread A aggiorna il valore della variabile e il thread B legge quella variabile subito dopo l'aggiornamento verrà visualizzato il valore più aggiornato che è stato scritto di recente dal thread A. Come ho letto in un C# 4.0 in poche parole book che questo è corretto perché

applicando volatili non impedisce una scrittura seguita da una lettura di essere scambiati.

Potrebbe questo problema essendo risolto mettendo Thread.MemoryBarrier() prima di ogni get della variabile volatile come:

private volatile bool _foo = false; 

private void A() 
{ 
    //… 
    Thread.MemoryBarrier(); 
    if (_foo) 
    { 
     //do somthing 
    } 
} 

private void B() 
{ 
    //… 
    _foo = true; 
    //… 
} 

E se questo risolve il problema; considera che abbiamo un ciclo while che dipende da quel valore in una delle sue condizioni; sta mettendo Thread.MemoryBarrier() prima del ciclo while è un modo corretto per risolvere il problema? Esempio:

private void A() 
{ 
    Thread.MemoryBarrier(); 
    while (_someOtherConditions && _foo) 
    { 
     // do somthing. 
    } 
} 

Per essere più precisi voglio la variabile _foo di dare il suo valore più fresco quando una qualsiasi discussione per chiedere in qualsiasi momento; quindi se l'inserimento Thread.MemoryBarrier() prima di chiamare la variabile risolve il problema, allora potrei usare Foo proprietà invece di _foo e fare un Thread.MemoryBarrier() all'interno del get di tale proprietà come:

Foo 
{ 
    get 
    { 
     Thread.MemoryBarrier(); 
     return _foo; 
    } 
    set 
    { 
     _foo = value; 
    } 
} 

Answer 1

"C# In a Nutshell" è corretto, ma la sua affermazione è discutibile. Perché?

• A 'scrittura' seguita da una 'lettura', withot 'volatili', è garantito a verificarsi in programma ordine comunque se effettua logica all'interno di un singolo filo
• Il 'write' prima di un 'leggi' in un programma multi-thread è completamente inutile di cui preoccuparsi nell'esempio.

Facciamo chiarezza. Prendete il vostro codice originale:

private void A() 
{ 
    //… 
    if (_foo) 
    { 
     //do something 
    } 
} 

Cosa succede se lo scheduler thread è già controllato la variabile _foo, ma viene sospesa poco prima che il commento //do something? Bene, a quel punto l'altro thread potrebbe cambiare il valore di _foo, il che significa che tutti i tuoi volatili e Thread.MemoryBarriers non hanno contato nulla !!! Se è assolutamente necessario evitare do_something se il valore di _foo è falso, non è possibile scegliere un blocco.

Tuttavia, se è corretto eseguire do something quando improvvisamente _foo diventa falso, significa che la parola chiave volatile è più che sufficiente per le proprie esigenze.

Per essere chiari: tutti i soccorritori che stanno dicendo di utilizzare una barriera di memoria non sono corretti o forniscono eccessivo.

Answer 2

Nel vostro secondo esempio, si avrebbe bisogno di mettere anche a Thread.MemoryBarrier(); all'interno del ciclo, per assicurarsi di ottenere il valore più recente ogni volta che si verifica la condizione del ciclo.

Answer 3

Tirato da here ...

class Foo 
{ 
    int _answer; 
    bool _complete; 

    void A() 
    { 
    _answer = 123; 
    Thread.MemoryBarrier(); // Barrier 1 
    _complete = true; 
    Thread.MemoryBarrier(); // Barrier 2 
    } 

    void B() 
    { 
    Thread.MemoryBarrier(); // Barrier 3 
    if (_complete) 
    { 
     Thread.MemoryBarrier();  // Barrier 4 
     Console.WriteLine (_answer); 
    } 
    } 
} 

Barriere 1 e 4 prevenire questo esempio da scrivere “0”. Le barriere 2 e 3 forniscono una garanzia di freschezza: esse assicurano che se B corri dopo A, la lettura di _complete valga su true.

Quindi, se torniamo al vostro esempio looping ... questo è come dovrebbe apparire ...

parole

private void A() 
{ 
    Thread.MemoryBarrier(); 
    while (_someOtherConditions && _foo) 
    { 
     //do somthing 
     Thread.MemoryBarrier(); 
    } 
} 

Answer 4

di Microsoft su barriere di memoria:

MemoryBarrier è richiesto solo su sistemi multiprocessore con ordini di memoria deboli (ad esempio, un sistema che utilizza più processori Intel Itanium).

Per la maggior parte degli scopi, l'istruzione C# lock, l'istruzione SyncLock di Visual Basic o la classe Monitor forniscono modi più semplici per sincronizzare i dati.

Answer 5

Il libro è corretto.
Il modello di memoria CLR indica che le operazioni di caricamento e memorizzazione possono essere riordinate. Questo vale per le variabili volatili e non volatile.

Dichiarazione di una variabile come volatile significa soltanto che le operazioni di carico avranno acquisiscono semantica, e memorizzare le operazioni avranno rilascio semantica. Inoltre, il compilatore eviterà di eseguire determinate ottimizzazioni che si relazionano sul fatto che la variabile viene acceduta in modo serializzato, a thread singolo (ad esempio carico/archivi di sollevamento fuori dai loop).

L'utilizzo della sola parola chiave volatile non crea sezioni critiche e non provoca la sincronizzazione magica dei thread tra loro.

Si dovrebbe essere estremamente attento quando si scrive codice di blocco libero. Non c'è niente di semplice in questo, e anche gli esperti hanno difficoltà a farlo bene.
Qualunque sia il problema originale che stai cercando di risolvere, è probabile che ci sia un modo molto più ragionevole per farlo.