Quando utilizzare 'volatile' o 'Thread.MemoryBarrier()' nel codice di blocco thread-safe? (C#)

Question

Quando si utilizza volatile/Thread.MemoryBarrier() per la sicurezza del thread?

Answer 1

Si utilizza volatile/Thread.MemoryBarrier() quando si desidera accedere a una variabile attraverso thread senza bloccare.

Le variabili che sono atomiche, ad esempio int, vengono sempre lette e scritte interamente insieme. Ciò significa che non otterrai mai metà del valore prima che un altro thread lo cambi e l'altra metà dopo che è stata modificata. Per questo puoi tranquillamente leggere e scrivere il valore in diversi thread senza syncronising.

Tuttavia, il compilatore può ottimizzare alcune letture e scritture, che vengono impedite con la parola chiave volatile.Se ad esempio avere un ciclo come questo:

sum = 0; 
foreach (int value in list) { 
    sum += value; 
} 

Il compilatore può effettivamente fare i calcoli in un registro del processore e solo scrivere il valore della variabile sum dopo il ciclo. Se si crea la variabile sumvolatile, il compilatore genererà il codice che legge e scrive la variabile per ogni modifica, in modo che il suo valore sia aggiornato in tutto il ciclo.

Answer 2

Cosa c'è di sbagliato con

private static readonly object syncObj = new object(); 
private static int counter; 

public static int NextValue() 
{ 
    lock (syncObj) 
    { 
     return counter++; 
    } 
} 

?

Questo fa tutto il necessario blocco, barriere di memoria, ecc. Per voi. È ben compreso e più leggibile di qualsiasi codice di sincronizzazione personalizzato basato su volatile e Thread.MemoryBarrier().

---

EDIT

non riesco a pensare ad uno scenario in cui mi piacerebbe utilizzare volatile o Thread.MemoryBarrier(). Ad esempio

private static volatile int counter; 

public static int NextValue() 
{ 
    return counter++; 
} 

è non equivalente al codice sopra ed è non thread-safe (volatile non opera ++ magicamente diventare thread-safe).

In un caso come questo:

private static volatile bool done; 

void Thread1() 
{ 
    while (!done) 
    { 
     // do work 
    } 
} 

void Thread2() 
{ 
    // do work 
    done = true; 
} 

(che dovrebbe funzionare) userei un ManualResetEvent per segnalare quando Thread2 è fatto.

Answer 3

In sostanza se si utilizza qualsiasi altro tipo di sincronizzazione per rendere il proprio codice non protetto, non è necessario.

La maggior parte dei meccanismi di blocco (incluso il blocco) implica automaticamente una barriera di memoria in modo che più processori possano ottenere le informazioni corrette.

Volatile e MemoryBarrier vengono principalmente utilizzati in scenari senza blocco in cui si tenta di evitare la penalizzazione delle prestazioni del blocco.

Edit: Si consiglia di leggere this article da Joe Duffy circa il modello di memoria CLR 2.0, chiarisce un sacco di cose (se siete veramente interessati vi consigliamo di leggere tutto l'articolo da Joe Duffie che è di grandi dimensioni il più esperto in parallelismo in .NET)

Answer 4

Poiché il nome implica volatile garantisce che il valore della cache venga svuotato in memoria in modo che tutti i thread vedano lo stesso valore. Ad esempio, se ho un numero intero la cui ultima scrittura è salvata nella cache, altri thread potrebbero non vederlo. Potrebbero persino vedere la loro copia cache di quell'intero. Marcare una variabile come volatile lo fa leggere direttamente dalla memoria.

Sriwantha Sri Aravinda Attanayake