Devo bloccare o contrassegnare come volatile quando si accede a un semplice flag booleano in C#?

Question

Diciamo solo che hai una semplice operazione che gira su un thread in background. Si desidera fornire un modo per annullare questa operazione in modo da creare un flag booleano impostato su true dal gestore di eventi click di un pulsante di annullamento.

private bool _cancelled; 

private void CancelButton_Click(Object sender ClickEventArgs e) 
{ 
    _cancelled = true; 
} 

Ora stai impostando il flag di annullamento dal thread della GUI, ma lo stai leggendo dal thread in background. Hai bisogno di bloccare prima di accedere al bool?

avresti bisogno per fare questo (e bloccare ovviamente nel gestore di eventi click tasto troppo):

while(operationNotComplete) 
{ 
    // Do complex operation 

    lock(_lockObject) 
    { 
     if(_cancelled) 
     { 
      break; 
     } 
    } 
} 

O è accettabile per fare questo (senza serratura):

while(!_cancelled & operationNotComplete) 
{ 
    // Do complex operation 
} 

O che dire della variabile _cancelled come volatile. È necessario?

[So che esiste la classe BackgroundWorker con il suo metodo CancelAsync() integrato, ma mi interessa la semantica e l'uso di accesso variabile e con accesso variabile ai thread qui, non l'implementazione specifica, il codice è solo un esempio. ]

Sembra esserci due teorie.

1) Perché è un semplice tipo integrato (e l'accesso ai tipi incorporati è atomico in .net) e poiché ci stiamo solo scrivendo in un posto e solo leggendo sul thread in background non è necessario bloccare o segna come volatile.
2) Dovresti contrassegnarlo come volatile perché se non lo fai il compilatore può ottimizzare la lettura del ciclo while perché non pensa nulla che sia in grado di modificare il valore.

Qual è la tecnica corretta? (E perché?)

[Modifica: Sembra che ci siano due scuole di pensiero chiaramente definite e opposte su questo. Sto cercando una risposta definitiva su questo quindi per favore se possibile postare le tue ragioni e citare le tue fonti insieme alla tua risposta.]

Answer 1

In primo luogo, la filettatura è difficile ;-p

Sì, nonostante tutte le voci al contrario, esso è tenuto a sia uso lockovolatile (ma non entrambi) quando si accede un bool da più thread.

Per i tipi e gli accessi semplici come un flag di uscita (bool), quindi volatile è sufficiente - questo garantisce che i thread non memorizzino il valore nei loro registri (ovvero: uno dei thread non vede mai gli aggiornamenti).

Per valori più grandi (dove atomicità è un problema), o dove si desidera sincronizzare un successione delle operazioni (un tipico esempio di essere "se non esiste e aggiungere" accesso dizionario), un lock è più versatile. Questo funge da barriera di memoria, quindi ti dà ancora la sicurezza del thread, ma fornisce altre funzionalità come pulse/wait. Si noti che non si dovrebbe usare un lock su un tipo di valore o un string; né Type o this; l'opzione migliore è avere il proprio oggetto di blocco come campo (readonly object syncLock = new object();) e bloccarlo.

Per un esempio di come si interrompe (ad esempio, il ciclo per sempre) se non si sincronizza - see here.

Per estendere più programmi, una primitiva del sistema operativo come o *ResetEvent può anche essere utile, ma questo è eccessivo per un singolo exe.

Answer 2

_cancelled deve essere volatile. (se non si sceglie di bloccare)

Se un thread modifica il valore di _cancelled, altri thread potrebbero non visualizzare il risultato aggiornato.

Inoltre, penso che le operazioni di lettura/scrittura di _cancelled sono atomica:

Sezione 12.6.6 degli stati CLI spec: "Un CLI conforme garantisce che in lettura e scrittura a correttamente posizioni di memoria allineate non più grandi rispetto alla dimensione nativa della parola è atomica quando tutti gli accessi in scrittura a una posizione hanno la stessa dimensione. "

Answer 3

Per la sincronizzazione dei thread, si consiglia di utilizzare una delle classi EventWaitHandle, ad esempio ManualResetEvent. Mentre è marginalmente più semplice utilizzare una semplice bandiera booleana come fai qui (e sì, dovresti contrassegnarla come volatile), IMO è meglio entrare nella pratica di usare gli strumenti di threading.Per i vostri scopi, si farebbe qualcosa di simile ...

private System.Threading.ManualResetEvent threadStop; 

void StartThread() 
{ 
    // do your setup 

    // instantiate it unset 
    threadStop = new System.Threading.ManualResetEvent(false); 

    // start the thread 
} 

nel tuo thread ..

while(!threadStop.WaitOne(0) && !operationComplete) 
{ 
    // work 
} 

Poi nella GUI di cancellare ...

threadStop.Set(); 

Answer 4

sguardo su Interlocked.Exchange(). Fa una copia molto veloce in una variabile locale che può essere utilizzata per il confronto. È più veloce di lock().

Answer 5

Il blocco non è richiesto perché si dispone di uno scenario di singolo writer e un campo booleano è una struttura semplice senza il rischio di corrompere lo stato (while it was possible to get a boolean value that is neither false nor true). Ma è necessario contrassegnare il campo come volatile per impedire al compilatore di eseguire alcune ottimizzazioni. Senza il modificatore volatile il compilatore poteva memorizzare il valore in un registro durante l'esecuzione del ciclo sul proprio thread di lavoro e, a sua volta, il ciclo non riconosceva mai il valore modificato. Questo articolo MSDN (How to: Create and Terminate Threads (C# Programming Guide)) risolve questo problema. Mentre è necessario il blocco, un blocco avrà lo stesso effetto del campo volatile.