¿Por qué necesitamos Thread.MemoryBarrier()?

Question

En "C# 4 en una cáscara de nuez", el autor muestra que esta clase puede escribir 0 veces sin MemoryBarrier, aunque no puedo reproducir en mi Core2Duo:

public class Foo 
{ 
    int _answer; 
    bool _complete; 
    public void A() 
    { 
     _answer = 123; 
     //Thread.MemoryBarrier(); // Barrier 1 
     _complete = true; 
     //Thread.MemoryBarrier(); // Barrier 2 
    } 
    public void B() 
    { 
     //Thread.MemoryBarrier(); // Barrier 3 
     if (_complete) 
     { 
      //Thread.MemoryBarrier();  // Barrier 4 
      Console.WriteLine(_answer); 
     } 
    } 
} 

private static void ThreadInverteOrdemComandos() 
{ 
    Foo obj = new Foo(); 

    Task.Factory.StartNew(obj.A); 
    Task.Factory.StartNew(obj.B); 

    Thread.Sleep(10); 
} 

Esta necesidad parece una locura para mí. ¿Cómo puedo reconocer todos los casos posibles que esto puede ocurrir? Creo que si el procesador cambia el orden de las operaciones, debe garantizar que el comportamiento no cambie.

¿Se molesta en usar Barriers?

Answer 1

Va a ser muy difícil reproducir este error. De hecho, iría tan lejos como para decir que nunca serás capaz de reproducirlo usando .NET Framework. La razón es porque la implementación de Microsoft usa un fuerte modelo de memoria para escrituras. Eso significa que las escrituras son tratadas como si fueran volátiles. Una escritura volátil tiene semántica de liberación de bloqueo, lo que significa que todas las escrituras previas deben confirmarse antes de la escritura actual.

Sin embargo, la especificación ECMA tiene un modelo de memoria más débil. Por lo tanto, es teóricamente posible que Mono o incluso una versión futura de .NET Framework comience a exhibir el comportamiento erróneo.

Entonces, lo que estoy diciendo es que es muy poco probable que eliminar las barreras # 1 y # 2 tenga un impacto en el comportamiento del programa. Eso, por supuesto, no es una garantía, sino una observación basada en la implementación actual del CLR solamente.

La eliminación de las barreras n. ° 3 y n. ° 4 definitivamente tendrá un impacto. Esto es bastante fácil de reproducir. Bueno, no este ejemplo per se, pero el siguiente código es una de las demostraciones más conocidas. Tiene que ser compilado usando la compilación Release y se ejecutó fuera del depurador. El error es que el programa no termina. Puede solucionar el error haciendo una llamada al Thread.MemoryBarrier dentro del lazo while o marcando stop como volatile.

class Program 
{ 
    static bool stop = false; 

    public static void Main(string[] args) 
    { 
     var t = new Thread(() => 
     { 
      Console.WriteLine("thread begin"); 
      bool toggle = false; 
      while (!stop) 
      { 
       toggle = !toggle; 
      } 
      Console.WriteLine("thread end"); 
     }); 
     t.Start(); 
     Thread.Sleep(1000); 
     stop = true; 
     Console.WriteLine("stop = true"); 
     Console.WriteLine("waiting..."); 
     t.Join(); 
    } 
} 

La razón por la cual algunos errores de roscado son difíciles de reproducir se debe a que las mismas tácticas que utilizan para simular el entrelazado de hilo en realidad puede corregir el error. Thread.Sleep es el ejemplo más notable porque genera barreras de memoria. Puede verificarlo haciendo una llamada dentro del bucle while y observando que el error desaparece.

Puede ver mi respuesta here para otro análisis del ejemplo del libro que ha citado.

Answer 2

Si usa volatile y lock, la barrera de memoria está incorporada. Pero, sí, la necesita de lo contrario. Habiendo dicho eso, sospecho que necesitas la mitad de lo que muestra tu ejemplo.

Answer 3

Es muy difícil de reproducir errores de subprocesos múltiples: por lo general, debe ejecutar el código de prueba muchas veces (miles) y tener algún control automático que marcará si se produce el error. Puede intentar agregar un Thread.Sleep (10) corto entre algunas de las líneas, pero nuevamente no siempre garantiza que obtendrá los mismos problemas que sin él.

Las barreras de memoria se introdujeron para las personas que necesitan hacer una optimización del rendimiento de bajo nivel muy difícil de su código multiproceso. En la mayoría de los casos, estará mejor cuando utilice otras primitivas de sincronización, es decir, volátiles o de bloqueo.

Answer 4

Si alguna vez toca datos de dos subprocesos diferentes, esto puede ocurrir. Este es uno de los trucos que los procesadores usan para aumentar la velocidad: podrías construir procesadores que no hicieran esto, pero serían mucho más lentos, por lo que ya nadie lo hace. Probablemente deberías leer algo como Hennessey and Patterson para reconocer todos los diversos tipos de condiciones de carrera.

Siempre uso algún tipo de herramienta de nivel superior, como un monitor o un candado, pero internamente están haciendo algo similar o están implementados con barreras.

Answer 5

Las probabilidades son muy bueno que la primera tarea se completa cuando la segunda tarea incluso comienza a ejecutarse. Solo puede observar este comportamiento si ambos subprocesos ejecutan ese código simultáneamente y no hay operaciones intermedias de sincronización de caché. Hay uno en su código, el método StartNew() tendrá un bloqueo dentro del administrador de grupo de subprocesos en alguna parte.

Obtener dos hilos para ejecutar este código simultáneamente es muy difícil. Este código se completa en un par de nanosegundos. Tendría que probar miles de millones de veces e introducir retrasos variables para tener probabilidades. No hay mucho que apuntar a esto, por supuesto, el verdadero problema es cuando esto ocurre al azar cuando no lo espera.

Aléjate de esto, utiliza la instrucción de bloqueo para escribir un código de varios subprocesos.

Answer 6

Voy a citar a uno de los grandes artículos sobre multi-threading:

Consideremos el siguiente ejemplo:

class Foo 
{ 
    int _answer; 
    bool _complete; 

    void A() 
    { 
    _answer = 123; 
    _complete = true; 
    } 

    void B() 
    { 
    if (_complete) Console.WriteLine (_answer); 
    } 
} 

Si los métodos A y B corrieron simultáneamente en diferentes hilos, ¿podría ser posible que B escriba "0"? La respuesta es sí, por las siguientes razones :

El compilador, CLR o CPU pueden reordenar las instrucciones de su programa a para mejorar la eficiencia. El compilador, el CLR o la CPU pueden introducir optimizaciones de almacenamiento en memoria caché de modo que las asignaciones a las variables no sean visibles para otros hilos de inmediato. C# y el tiempo de ejecución son muy cuidadosos al asegurarse de que tales optimizaciones no rompan el código ordinario de un solo subproceso - o código multiproceso que hace un uso adecuado de los bloqueos. Fuera de de estos escenarios, debe derrotar explícitamente estas optimizaciones por creando barreras de memoria (también llamadas vallas de memoria) para limitar los efectos de reordenamiento de instrucciones y caché de lectura/escritura.

vallas completas

El tipo más simple de barrera de la memoria es una memoria llena barrera (completa valla) que impide cualquier tipo de instrucción reordenación o caché de alrededor de esa valla. Calling Thread.MemoryBarrier genera una valla completa ; podemos fijar nuestro ejemplo mediante la aplicación de cuatro vallas completos como sigue:

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

Toda la teoría detrás de Thread.MemoryBarrier y por qué tenemos que utilizar en escenarios de no bloqueo para hacer el código seguro y robusto se describe muy bien aquí: http://www.albahari.com/threading/part4.aspx