volátil y Thread.MemoryBarrier en C#

Question

para implementar un bloqueo de código libre para multithreading aplicación Solía ​​volatile variables, Teóricamente: La palabra clave volatile se utiliza simplemente para asegurarse de que todos los hilos ver el valor más actualizada de una variable volátil; así que si el hilo A actualiza el valor de la variable y el hilo B lee esa variable justo después de que se haya realizado la actualización verá el valor más actualizado escrito recientemente desde el hilo A. Cuando leo en un C# 4.0 en Nutshell libro que esto es incorrecto porque

aplicar volátil no impide que una escritura seguido de una lectura de ser intercambiado.

Podría este problema a resolver poniendo Thread.MemoryBarrier() antes de cada get de la variable volatile como:

private volatile bool _foo = false; 

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

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

Y si esto resuelve el problema; consideramos que tenemos un ciclo while que depende de ese valor en una de sus condiciones; está poniendo Thread.MemoryBarrier() antes del ciclo while es una forma correcta de solucionar el problema? ejemplo:

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

Para ser más exacto que quiero la variable _foo para dar su valor más fresco cuando cualquier tema preguntando por él en cualquier momento; por lo que si la inserción Thread.MemoryBarrier() antes de llamar a la variable fija el problema, entonces podría utilizar Foo propiedad en lugar de _foo y hacer un Thread.MemoryBarrier() dentro de la escapada de esa propiedad como:

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

Answer 1

El "C# In a Nutshell" es correcto, pero su declaración es irrelevante. ¿Por qué?

• A 'escritura' seguido de un 'leer', withot 'volátil', se garantiza que se produzca en el programa de orden de todos modos si efectúa lógica dentro de un solo hilo
• El 'escribir' antes de una 'leer' en un programa multiproceso es completamente inútil de qué preocuparse en su ejemplo.

Aclaremos. Tome su código original:

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

¿Qué pasa si el programador de subprocesos ya ha comprobado la variable _foo, pero se suspendió justo antes del comentario //do something? Bueno, en ese punto su otro hilo podría cambiar el valor de _foo, lo que significa que todos sus componentes volátiles y Thread.MemoryBarriers contaron en vano !!! Si es absolutamente esencial que se evite el do_something si el valor de _foo es falso, entonces no tiene más remedio que usar un candado.

Sin embargo, si está bien que el do something se esté ejecutando cuando de repente _foo se convierte en falso, significa que la palabra clave volátil fue más que suficiente para sus necesidades.

Para ser claros: todos los que respondieron que le dicen que use una barrera de memoria son incorrectos o están dando excesos.

Answer 2

En el segundo ejemplo, se necesitaría poner también un Thread.MemoryBarrier(); dentro del ciclo, para asegurarse de obtener el valor más reciente cada vez que verifique la condición del ciclo.

Answer 3

sacado de 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); 
    } 
    } 
} 

Barreras 1 y 4 evitar este ejemplo de escribir “0”. Las barreras 2 y 3 proporcionan una garantía de frescura: garantizan que si B se ejecutó después de A, la lectura de _completa sería verdadera.

Así que si volvemos al ejemplo de su bucle ... así es como debería ser ...

propias palabras

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

Answer 4

de Microsoft sobre las barreras de memoria: Se requiere

MemoryBarrier sólo en sistemas multiprocesador con orden de memoria débil (por ejemplo, un sistema que emplea múltiples procesadores Intel Itanium).

Para la mayoría de los propósitos, la instrucción de bloqueo C#, la instrucción SyncLock de Visual Basic o la clase Monitor proporcionan formas más fáciles de sincronizar datos.

Answer 5

El libro es correcto.
El modelo de memoria del CLR indica que las operaciones de carga y almacenamiento pueden reordenarse. Esto se aplica a las variables volátiles y no volátiles.

Declarar una variable como volatile sólo significa que las operaciones de carga tendrán adquieren semántica y operaciones de la tienda tendrán liberación semántica. Además, el compilador evitará realizar ciertas optimizaciones que se transmiten por el hecho de que se accede a la variable de manera serializada y con un único subproceso (por ejemplo, carga/almacenamiento de bucles).

El uso de la palabra clave volatile solo no crea secciones críticas, y no hace que los subprocesos se sincronicen mágicamente entre sí.

Debe ser extremadamente cuidado al escribir el código de bloqueo. No hay nada simple al respecto, e incluso los expertos tienen problemas para hacerlo bien.
Cualquiera que sea el problema original que está tratando de resolver, es probable que haya una forma mucho más razonable de hacerlo.