c# - 何时使用 volatile 来抵消 C# 中的编译器优化

Question

我花了大量时间在 C# 4.0 中进行多线程编码。然而，有一个问题对我来说仍然没有答案。

我知道 volatile 关键字会阻止编译器将变量存储在寄存器中，从而避免无意中读取过时的值。写入在 .Net 中总是易变的，因此任何说明它还避免过时写入的文档都是多余的。

我也知道编译器优化有点“不可预测”。以下代码将说明由于编译器优化(在 VS 之外运行发布编译时)导致的停顿:

class Test
{
    public struct Data
    {
        public int _loop;
    }

    public static Data data;

    public static void Main()
    {
        data._loop = 1;
        Test test1 = new Test();

        new Thread(() =>
        {
            data._loop = 0;
        }
        ).Start();

        do
        {
            if (data._loop != 1)
            {
                break;
            }

            //Thread.Yield();
        } while (true);

        // will never terminate
    }
}

代码按预期运行。但是，如果我取消注释//Thread.Yield();行，然后循环将退出。

此外，如果我在 do 循环之前放置一个 Sleep 语句，它将退出。我不明白。

自然地，用 volatile 装饰 _loop 也会导致循环退出(以其显示的模式)。

我的问题是:编译器遵循哪些规则来确定何时隐式执行 volatile 读取？为什么我仍然可以让循环以我认为是奇怪的措施退出？

编辑

IL 代码如图所示(停顿):

L_0038: ldsflda valuetype ConsoleApplication1.Test/Data ConsoleApplication1.Test::data
L_003d: ldfld int32 ConsoleApplication1.Test/Data::_loop
L_0042: ldc.i4.1 
L_0043: beq.s L_0038
L_0045: ret 

IL 与 Yield()(不停止):

L_0038: ldsflda valuetype ConsoleApplication1.Test/Data ConsoleApplication1.Test::data
L_003d: ldfld int32 ConsoleApplication1.Test/Data::_loop
L_0042: ldc.i4.1 
L_0043: beq.s L_0046
L_0045: ret 
L_0046: call bool [mscorlib]System.Threading.Thread::Yield()
L_004b: pop 
L_004c: br.s L_0038

Answer 1

What are the rules the complier follows in order to determine when to implicity perform a volatile read?

首先，不仅仅是编译器移动指令。导致指令重新排序的三大角色是:

编译器(如 C# 或 VB.NET)

运行时(如 CLR 或 Mono)

硬件(如 x86 或 ARM)

硬件级别的规则更加简洁，因为它们通常被很好地记录下来。但是，在运行时和编译器级别，内存模型规范对指令如何重新排序提供了限制，但由实现者决定他们想要优化代码的积极程度以及他们想要遵守的程度关于内存模型约束。

例如，CLI 的 ECMA 规范提供了相当薄弱的保证。但微软决定在 .NET Framework CLR 中加强这些保证。除了一些博客文章之外，我还没有看到太多关于 CLR 遵守的规则的正式文档。当然，Mono 可能会使用一组不同的规则，这些规则可能会也可能不会使其更接近 ECMA 规范。当然，只要仍考虑正式的 ECMA 规范，在 future 版本中更改规则可能会有一些自由。

综上所述，我有几点看法:

使用 Release 配置进行编译更有可能导致指令重新排序。

更简单的方法更有可能对其指令进行重新排序。

将循环内部的读取提升到循环外部是一种典型的重新排序优化类型。

And why can I still get the loop to exit with what I consider to be odd measures?

这是因为那些“奇怪的措施”正在做两件事之一:

生成隐式内存屏障

绕过编译器或运行时执行某些优化的能力

例如，如果方法中的代码过于复杂，它可能会阻止 JIT 编译器执行某些重新排序指令的优化。你可以把它想象成有点像复杂的方法也不会被内联。

此外，诸如 Thread.Yield 之类的东西和 Thread.Sleep创建隐式内存障碍。我已经开始列出此类机制 here .我敢打赌，如果您输入 Console.WriteLine在您的代码中调用它也会导致循环退出。我还看到“非终止循环”示例在不同版本的 .NET Framework 中表现不同。例如，我敢打赌，如果您在 1.0 中运行该代码，它将终止。

这就是为什么使用 Thread.Sleep模拟线程交错实际上可以掩盖内存屏障问题。

更新:

在阅读了您的一些评论后，我认为您可能对 Thread.MemoryBarrier 的内容感到困惑。实际上是在做。它的作用是创建一个完整的围栏屏障。这究竟是什么意思？全围栏屏障是两个半围栏的组合:获取围栏和释放围栏。我现在将定义它们。

获取栅栏:在栅栏之前不允许其他读写操作的内存栅栏。

释放栅栏:在栅栏之后不允许其他读写操作的内存栅栏。

因此，当您看到拨打 Thread.MemoryBarrier 的电话时它将防止所有读取和写入移动到屏障上方或下方。它还会发出任何需要的 CPU 特定指令。

如果您查看 Thread.VolatileRead 的代码这是你会看到的。

public static int VolatileRead(ref int address)
{
    int num = address;
    MemoryBarrier();
    return num;
}

现在您可能想知道为什么 MemoryBarrier调用是在实际读取之后。您的直觉可能会告诉您，要“重新”阅读 address您需要调用 MemoryBarrier在读取之前发生。但是，唉，你的直觉是错误的!规范说一个 volatile 读应该产生一个获取栅栏屏障。根据我上面给你的定义，这意味着调用 MemoryBarrier必须在阅读 address 之后以防止在它之前移动其他读取和写入。您会看到 volatile 读取并不是严格意义上的“新鲜”读取。它是关于防止指令的移动。这令人难以置信的困惑；我知道。