在 C# 中模拟撕裂双精度数

Question

我在 32 位机器上运行，并且我能够使用以下快速命中的代码片段来确认长值可能会被破坏。

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

但当我尝试用双打做类似的事情时，我无法得到任何撕裂。有谁知道为什么？据我从规范中可以看出，只有对浮点数的赋值是原子的。分配给双打应该有撕裂的风险。

    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;

当您使用双精度时，要展示效果要困难得多。 CPU 使用专用指令来加载和存储双精度型，分别为 FLD 和 FSTP。使用long要容易得多，因为没有单个指令可以在 32 位模式下加载/存储 64 位整数。要观察它，您需要使变量的地址未对齐，以便它跨越 cpu 缓存行边界。

您使用的声明永远不会发生这种情况，JIT 编译器确保双精度正确对齐，存储在 8 的倍数的地址中。您可以将它存储在类的字段中，GC 分配器仅与 4 对齐32 位模式。但这是一个废话。

最好的方法是使用指针有意地错位双精度数。将 unsafe 放在 Program 类前面，并使其看起来与此类似：

    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;

这仍然不能保证良好的未对齐（呵呵），因为无法准确控制 AllocCoTaskMem() 将对齐分配的位置相对于 cpu 高速缓存行的开始。这取决于您的 cpu 核心（我的是 Core i5）中的缓存关联性。你必须修改偏移量，我通过实验得到了值 28。该值应能被 4 整除，但不能被 8 整除，才能真正模拟 GC 堆行为。继续向该值添加 8，直到获得跨越缓存行并触发断言的双精度值。

为了减少人工，您必须编写一个程序来存储类字段中的双精度值，并让垃圾收集器在内存中移动它，以便它不对齐。很难想出一个示例程序来确保发生这种情况。

另请注意您的程序如何演示称为“错误共享”的问题。注释掉线程 B 的 Start() 方法调用，并注意线程 A 的运行速度快了多少。您会看到 cpu 保持 cpu 核心之间的缓存线一致的成本。这里意在共享，因为线程访问相同的变量。当线程访问存储在同一缓存行中的不同变量时，就会发生真正的错误共享。否则，这就是对齐很重要的原因，只有当双精度值的一部分位于一个缓存行而部分位于另一缓存行时，您才能观察到双精度的撕裂。

Answer 2

听起来很奇怪，但这取决于您的 CPU。虽然双打不能保证不会撕裂，但在许多当前的处理器上却不会。如果您想在这种情况下出现撕裂，请尝试 AMD Sempron。

编辑：几年前艰难地了解到这一点。

Answer 3

经过一番挖掘，我发现了一些有关 x86 架构上浮点运算的有趣读物：

根据 维基百科，x86浮点单元在80位寄存器中存储浮点值：

[...] 随后的 x86 处理器随后集成了此 x87 功能
在芯片上，这使得 x87 指令成为事实上的组成部分
x86 指令集。每个 x87 寄存器，称为 ST(0) 到
ST(7)，80 位宽，以 IEEE 浮点形式存储数字
标准双扩展精度格式。

另外这个问题也是相关的： 一些浮点精度和数字限制问题

这可以解释为什么虽然双精度数是 64 位，但它们是原子操作的。

Answer 4

对于本主题和代码示例的价值，可以在此处找到。

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