Simular rasgar un doble en C#

Question

Me estoy ejecutando en una máquina de 32 bits y puedo confirmar que los valores largos pueden rasgarse usando el siguiente fragmento de código que se ejecuta muy rápido.

 static void TestTearingLong() 
     { 
      System.Threading.Thread A = new System.Threading.Thread(ThreadA); 
      A.Start(); 

      System.Threading.Thread B = new System.Threading.Thread(ThreadB); 
      B.Start(); 
     } 

     static ulong s_x; 

     static void ThreadA() 
     { 
      int i = 0; 
      while (true) 
      { 
       s_x = (i & 1) == 0 ? 0x0L : 0xaaaabbbbccccddddL; 
       i++; 
      } 
     } 

     static void ThreadB() 
     { 
      while (true) 
      { 
       ulong x = s_x; 
       Debug.Assert(x == 0x0L || x == 0xaaaabbbbccccddddL); 
      } 
     } 

Pero cuando intento algo similar con los dobles, no consigo desgarrarme. ¿Alguien sabe por qué? Por lo que puedo decir de la especificación, solo la asignación a un flotador es atómica. La asignación a un doble debe tener un riesgo de desgarro.

static double s_x; 

    static void TestTearingDouble() 
    { 
     System.Threading.Thread A = new System.Threading.Thread(ThreadA); 
     A.Start(); 

     System.Threading.Thread B = new System.Threading.Thread(ThreadB); 
     B.Start(); 
    } 

    static void ThreadA() 
    { 
     long i = 0; 

     while (true) 
     { 
      s_x = ((i & 1) == 0) ? 0.0 : double.MaxValue; 
      i++; 

      if (i % 10000000 == 0) 
      { 
       Console.Out.WriteLine("i = " + i); 
      } 
     } 
    } 

    static void ThreadB() 
    { 
     while (true) 
     { 
      double x = s_x; 

      System.Diagnostics.Debug.Assert(x == 0.0 || x == double.MaxValue); 
     } 
    } 

Answer 1

static double s_x; 

Es mucho más difícil de demostrar el efecto cuando se utiliza un doble. La CPU utiliza instrucciones específicas para cargar y almacenar un doble, respectivamente FLD y FSTP. Es mucho más fácil con largo ya que no hay instrucciones únicas que carguen/almacenen un entero de 64 bits en el modo de 32 bits. Para observarlo, es necesario que la dirección de la variable esté desalineada para que se extienda a ambos lados del límite de la línea de caché de la CPU.

Eso nunca sucederá con la declaración que utilizó, el compilador JIT asegura que el doble está alineado correctamente, almacenado en una dirección que es un múltiplo de 8. Puede almacenarlo en un campo de una clase, el asignador GC solamente se alinea a 4 en modo de 32 bits. Pero eso es una mierda.

La mejor manera de hacerlo es alineando incorrectamente el doble utilizando un puntero.Ponga insegura frente a la clase del Programa y hacer que parezca similar a esto:

static double* s_x; 

    static void Main(string[] args) { 
     var mem = Marshal.AllocCoTaskMem(100); 
     s_x = (double*)((long)(mem) + 28); 
     TestTearingDouble(); 
    } 
ThreadA: 
      *s_x = ((i & 1) == 0) ? 0.0 : double.MaxValue; 
ThreadB: 
      double x = *s_x; 

Esto todavía no garantizará una buena desalineación (jeje) ya que no hay manera de controlar exactamente donde AllocCoTaskMem() se alineará la asignación relativa al inicio de la línea de caché de la CPU. Y depende de la asociatividad del caché en su núcleo de la CPU (el mío es un Core i5). Tendrás que jugar con el desplazamiento, obtuve el valor 28 por experimentación. El valor debe ser divisible entre 4 pero no entre 8 para simular realmente el comportamiento del montón de GC. Siga agregando 8 al valor hasta que obtenga el doble para montar a horcajadas en la línea de caché y activar la afirmación.

Para hacerlo menos artificial tendrás que escribir un programa que almacene el doble en el campo de una clase y conseguir que el recolector de basura lo mueva en la memoria para que quede desalineado. Es un poco difícil encontrar un programa de muestra que asegure esto sucede.

También tenga en cuenta cómo su programa puede mostrar un problema llamado compartir falsa. Comente la llamada al método Start() para el subproceso B y observe cuánto más rápido se ejecuta el subproceso A. Está viendo el costo de la CPU manteniendo constante la línea de caché entre los núcleos de la CPU. Compartir está pensado aquí ya que los hilos acceden a la misma variable. El intercambio falso real ocurre cuando los subprocesos tienen acceso a diferentes variables que están almacenadas en la misma línea de caché. Por lo demás, esta es la razón por la cual la alineación es importante, solo se puede observar el rasgado de un doble cuando parte de él está en una línea de caché y parte de él está en otra.

Answer 2

Por extraño que parezca, eso depende de su CPU. Mientras que los dobles son no garantizados no se rompen, no lo harán en muchos procesadores actuales. Prueba un AMD Sempron si quieres desgarrarte en esta situación.

EDIT: aprendido de la manera difícil hace unos años.

Answer 3

Hacer algo de investigación, he encontrado algunas interesantes lee acerca de las operaciones de punto flotante en arquitecturas x86:

valores de punto flotante

Según Wikipedia, el x86 unidad de coma flotante almacenados en los registros de 80 bits:

[...] procesadores x86 posteriores después se integra esta funcionalidad x87 en el chip que hizo que el facto una parte de las instrucciones x87 integral de el conjunto de instrucciones x86. Cada registro x87, conocido como ST (0) a ST (7), tiene 80 bits de ancho y almacena números en el formato de precisión extendida doble IEEE de punto flotante .

También esta pregunta otra SO está relacionado: Some floating point precision and numeric limits question

Esto podría explicar por qué, a pesar de los dobles son de 64 bits, que son operadas en forma atómica.

Answer 4

Por lo que vale, este tema y el ejemplo de código se pueden encontrar aquí.

http://msdn.microsoft.com/en-us/magazine/cc817398.aspx