Leyendoesta pregunta, Quería probar si podía demostrar la no atomicidad de las lecturas y escrituras en un tipo para el cual no se garantiza la atomicidad de tales operaciones.

private static double _d;

[STAThread]
static void Main()
{
    new Thread(KeepMutating).Start();
    KeepReading();
}

private static void KeepReading()
{
    while (true)
    {
        double dCopy = _d;

        // In release: if (...) throw ...
        Debug.Assert(dCopy == 0D || dCopy == double.MaxValue); // Never fails
    }
}

private static void KeepMutating()
{
    Random rand = new Random();
    while (true)
    {
        _d = rand.Next(2) == 0 ? 0D : double.MaxValue;
    }
}

Para mi sorpresa, la afirmación se negó a fallar incluso después de tres minutos completos de ejecución. ¿Lo que da?

La prueba es incorrecta.Las características de tiempo específicas de la prueba hacen improbable / imposible que la afirmación falle.La probabilidad es tan baja que tengo que ejecutar la prueba durante mucho más tiempo para que sea probable que se active.El CLR ofrece garantías más fuertes sobre la atomicidad que la especificación C #.Mi sistema operativo / hardware ofrece garantías más fuertes que el CLR.¿Algo más?

Por supuesto, no tengo la intención de confiar en ningún comportamiento que no esté explícitamente garantizado por la especificación, pero me gustaría una comprensión más profunda del problema.

FYI, ejecuté esto en Debug y Release (cambiandoDebug.Assert aif(..) throw) perfiles en dos entornos separados:

Windows 7 de 64 bits + .NET 3.5 SP1Windows XP 32 bits + .NET 2.0

EDITAR: Para excluir la posibilidad de que el comentario de John Kugelman "el depurador no es seguro para Schrodinger" sea el problema, agregué la líneasomeList.Add(dCopy); alKeepReading método y verificó que esta lista no estaba viendo un único valor obsoleto de la memoria caché.

EDITAR: Basado en la sugerencia de Dan Bryant: Usarlong en lugar dedouble lo rompe virtualmente al instante.