我们为什么需要Thread.MemoryBarrier（）？ [英] Why we need Thread.MemoryBarrier()?

问题描述

在果壳中的C＃4中，作者表明该类可以写0有时没有 MemoryBarrier ，虽然我不能在我的Core 2 Duo复制：

In "C# 4 in a Nutshell", the author shows that this class can write 0 sometimes without MemoryBarrier, though I can't reproduce in my 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);
}

这需要太疯狂了我。我怎么能认识到这所有可能发生的情况？我认为，如果处理器改变操作顺序，它需要保证的行为不会改变。

This need seems crazy to me. How can I recognize all possible cases that this can occur? I think that if processor changes order of operations, it needs to guarantee that the behavior doesn't change.

你懒得用贸易壁垒？

推荐答案

您将拥有一个非常困难的时期再现这个bug。事实上，我会尽量去的话，你将永远无法使用.NET Framework重现它。究其原因是因为微软的实现使用用于写一个强大的内存模型。这意味着写操作被视为好像它们是挥发性的。挥发性写有锁释放的语义，这意味着所有的写操作之前，必须在当前写入之前被提交。

You are going to have a very hard time reproducing this bug. In fact, I would go as far as saying you will never be able to reproduce it using the .NET Framework. The reason is because Microsoft's implementation uses a strong memory model for writes. That means writes are treated as if they were volatile. A volatile write has lock-release semantics which means that all prior writes must be committed before the current write.

然而，ECMA规范有一个较弱的内存模型。因此，在理论上是可能的，单声道或.NET Framework的甚至是将来的版本可能会开始表现出的错误行为。

However, the ECMA specification has a weaker memory model. So it is theoretically possible that Mono or even a future version of the .NET Framework might start exhibiting the buggy behavior.

所以，我的意思是，这是不太可能，消除障碍＃1和＃2将会对程序的行为产生任何影响。当然，这是不能保证，但基于CLR当前执行的观察而已。

So what I am saying is that it is very unlikely that removing barriers #1 and #2 will have any impact on the behavior of the program. That, of course, is not a guarantee, but an observation based on the current implementation of the CLR only.

消除障碍＃3，＃4肯定会产生影响。这实际上是pretty的容易重现。哦，不是这个例子本身，而是下面的code是比较知名的示威活动之一。它使用发布版本进行编译和调试器之外运行。该缺陷是，该计划并没有结束。您可以通过将呼叫 Thread.MemoryBarrier 的，而循环内或通过标记修复bug 停止为挥发性。

Removing barriers #3 and #4 will definitely have an impact. This is actually pretty easy to reproduce. Well, not this example per se, but the following code is one of the more well known demonstrations. It has to be compiled using the Release build and ran outside of the debugger. The bug is that the program does not end. You can fix the bug by placing a call to Thread.MemoryBarrier inside the while loop or by marking stop as 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();
    }
}

之所以有些线程错误是难以复制的，因为你用模拟线交织同样的手法其实可以修复的bug。 Thread.sleep代码就是最明显的例子，因为它产生记忆障碍。您可以验证通过将呼叫，而循环内，并且观察到的错误消失。

The reason why some threading bugs are hard to reproduce is because the same tactics you use to simulate thread interleaving can actually fix the bug. Thread.Sleep is the most notable example because it generates memory barriers. You can verify that by placing a call inside the while loop and observing that the bug goes away.

您可以看到我的回答<一href="http://stackoverflow.com/questions/3493931/why-do-i-need-a-memorybarrier/3495287#3495287">here从您列举了书中的示例的另一分析。

You can see my answer here for another analysis of the example from the book you cited.

这篇关于我们为什么需要Thread.MemoryBarrier（）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！