Ho bisogno che questo campo sia volatile?

Question

Ho un thread che gira finché un int modificato da un altro thread è un determinato valore.

int cur = this.m_cur; 
while (cur > this.Max) 
{ 
    // spin until cur is <= max 
    cur = this.m_cur; 
} 

Questo file.m_cur deve essere dichiarato volatile perché funzioni? È possibile che questo giri per sempre a causa dell'ottimizzazione del compilatore?

Answer 1

Sì, questo è un requisito difficile. Il compilatore just-in-time è autorizzato a memorizzare il valore di m_cur in un registro del processore senza aggiornarlo dalla memoria. Il jitter x86 infatti lo fa, il jitter x64 non lo fa (almeno l'ultima volta che l'ho guardato).

volatile La parola chiave è necessaria per sopprimere questa ottimizzazione.

Volatile significa qualcosa di completamente diverso sui core Itanium, un processore con un modello di memoria debole. Sfortunatamente è ciò che ha reso la libreria MSDN e la specifica del linguaggio C#. Resta da vedere cosa significherà su un nucleo ARM.

Answer 2

Il blog sotto ha alcuni dettagli affascinanti sul modello di memoria in C#. In breve, sembra più sicuro usare la parola chiave volatile.

http://igoro.com/archive/volatile-keyword-in-c-memory-model-explained/

Dal blog di sotto

class Test 
{ 
    private bool _loop = true; 

    public static void Main() 
    { 
     Test test1 = new Test(); 

     // Set _loop to false on another thread 
     new Thread(() => { test1._loop = false;}).Start(); 

     // Poll the _loop field until it is set to false 
     while (test1._loop == true) ; 

     // The loop above will never terminate! 
    } 
} 

Ci sono due possibili modi per ottenere il ciclo while per terminare: utilizzare un blocco per proteggere tutti gli accessi (letture e scritture) al _loop field Contrassegna il campo _loop come volatile Ci sono due motivi per cui una lettura di un campo non volatile può osservare un valore non aggiornato: ottimizzazioni del compilatore e ottimizzazioni del processore.

Answer 3

Dipende da come m_cur viene modificato. Se sta usando una normale istruzione di assegnazione come m_cur--;, allora deve essere volatile. Tuttavia, se viene modificato utilizzando una delle operazioni Interlocked, ciò non avviene perché i metodi di Interlocked inseriscono automaticamente una barriera di memoria per garantire che tutti i thread ottengano il memo.

In generale, l'opzione preferibile è l'utilizzo di Interlock per modificare valori atomici condivisi tra thread. Non solo si prende cura della barriera di memoria per te, ma tende anche ad essere un po 'più veloce rispetto ad altre opzioni di sincronizzazione.

Detto questo, come altri hanno detto che i cicli di polling sono enormemente dispendiosi. Sarebbe meglio mettere in pausa il thread che deve aspettare, e lasciare che chiunque modifichi m_cur si faccia carico di svegliarlo quando arriverà il momento. Sia Monitor.Wait() and Monitor.Pulse() e AutoResetEvent potrebbero essere adatti all'attività, a seconda delle esigenze specifiche.