Question

我经常听说在.NET 2.0内存模型中，写入始终使用释放围栏。这是真的？这是否意味着即使没有明确的内存屏障或锁定，也不可能在不同于创建它的线程上观察部分构造的对象（仅考虑引用类型）？我显然排除了构造函数泄漏this引用的情况。

例如，假设我们有不可变的引用类型：

public class Person
{
    public string Name { get; private set; }
    public int Age { get; private set; }

    public Person(string name, int age)
    {
        Name = name;
        Age = age;
    }
}

使用以下代码是否可以观察“John 20”和“Jack 21”以外的任何输出，比如说“null 20”或“Jack 0”？

// We could make this volatile to freshen the read, but I don't want
// to complicate the core of the question.
private Person person;

private void Thread1()
{
    while (true)
    {
        var personCopy = person;

        if (personCopy != null)
            Console.WriteLine(personCopy.Name + " " + personCopy.Age);
    }
}

private void Thread2()
{
    var random = new Random();

    while (true)
    {
        person = random.Next(2) == 0
            ? new Person("John", 20)
            : new Person("Jack", 21);
    }
}

这是否也意味着我可以创建深度不可变引用类型volatile的所有共享字段，并且（在大多数情况下）只是继续我的工作？

Answer 1

我经常听说在.NET 2.0内存模型中，写总是使用释放栅栏。这是真的吗？

这取决于您所指的模型。

首先，让我们精确定义一个释放栅栏屏障。释放语义规定，在该障碍之后，不允许在指令序列中的障碍之前出现其他读或写。

ECMA规范有一个宽松的模型，其中写入不提供此保证。
在某些地方引用过，微软提供的CLR实现通过使写入具有发布范围语义来强化模型。
x86和x64架构通过编写释放栅栏障碍并读取获取栅栏障碍来强化模型。

因此，在深奥的体系结构（如Windows 8现在将以ARM为目标）上运行的CLI（如Mono）的另一个实现可能不在写入时提供释放范围语义。请注意，我说这是可能的，但不确定。但是，在所有正在运行的内存模型之间，例如不同的软件和硬件层，如果您希望代码真正可移植，则必须为最弱的模型编写代码。这意味着编码ECMA模型而不做任何假设。

我们应该制作一个显式的内存模型层列表。

编译器：C＃（或VB.NET或其他）可以移动指令。
运行时：显然，通过JIT编译器的CLI运行时可以移动指令。
硬件：当然，CPU和内存架构也会发挥作用。

这是否意味着即使没有明确的记忆障碍或锁定，它也是如此是不可能观察到部分构造的物体（考虑到仅限引用类型）在与其不同的线程上是创造了吗？

是（合格）：如果运行应用程序的环境模糊不清，则可能会从另一个线程中观察到部分构造的实例。这是在不使用volatile的情况下双重检查锁定模式不安全的原因之一。但实际上，我怀疑你会遇到这种情况，主要是因为微软的CLI实现不会以这种方式重新排序指令。

使用以下代码可以观察任何输出除了“John 20”和“Jack 21”之外，说“null 20”或“Jack 0”？

同样，这是合格的。但由于上述某些原因，我怀疑你会不会观察到这种行为。

虽然，我应该指出，因为person未标记为volatile，所以可能根本没有打印任何内容，因为阅读主题可能始终将其视为null。但实际上，我打赌Console.WriteLine调用将导致C＃和JIT编译器避免提升操作，否则可能会将person的读取移到循环之外。我怀疑你已经很清楚这种细微差别了。

这是否也意味着我可以创建所有共享字段深度不可变的引用类型volatile和（在大多数情况下）继续我的工作？

我不知道。这是一个非常有问题的问题。如果不更好地理解它背后的背景，我会不自在地回答这两种方式。我可以说的是，我通常会避免使用volatile支持更明确的内存指令，例如Interlocked操作，Thread.VolatileRead，Thread.VolatileWrite和Thread.MemoryBarrier 。然后，我还尝试完全避免使用非锁定代码来支持更高级别的同步机制，例如lock。

<强>更新

我喜欢可视化的一种方式是假设C＃编译器，JITer等将尽可能积极地进行优化。这意味着Person.ctor可能是内联的候选者（因为它很简单）会产生以下伪代码。

Person ref = allocate space for Person
ref.Name = name;
ref.Age = age;
person = instance;
DoSomething(person);

因为写入在ECMA规范中没有发布 - 围栏语义，所以其他读取＆amp;写入可以“浮动”到作为person的赋值之后，产生以下有效的指令序列。

Person ref = allocate space for Person
person = ref;
person.Name = name;
person.Age = age;
DoSomething(person);

因此，在这种情况下，您可以看到person在初始化之前已分配。这是有效的，因为从执行线程的角度来看，逻辑序列与物理序列保持一致。没有意想不到的副作用。但是，由于显而易见的原因，这个序列对另一个线程来说是灾难性的。

Answer 2

你没有希望。用错误检查替换你的控制台写入，设置一个Thread1（）的十几个副本，使用一个有4个核心的机器，你必然会找到一些部分构造的Person实例。使用其他答案和评论中提到的保证技术，以确保您的程序安全。

编写编译器的人和创建CPU的人都在追求更快的速度，密谋使情况变得更糟。如果没有明确的指示，编译人员将以任何方式重新排序您的代码以节省纳秒。 CPU人员也在做同样的事情。最后我读到，如果可以，单核往往会同时运行4条指令。（也许即使它不能。）

在正常情况下，您很少遇到此问题。然而，我发现，每6个月只出现一次的小问题可能是一个真正的主要问题。而且，有趣的是，十分之一的问题每分钟都会发生几次 - 这是更可取的。我猜你的代码将属于后一类。

Answer 3

好吧，至少在IL级别，构造函数直接在堆栈上调用，生成的引用不会生成（并且能够存储），直到构造完成。因此，它不能在（IL）编译器级别（对于引用类型）重新排序。

至于抖动级别，我不确定，但是如果重新排序字段赋值和方法调用（这是构造函数的话）会让我感到惊讶。编译器是否真的会查看该方法及其所有方法可能的执行路径，以确保被调用的方法永远不会使用该字段？

同样在CPU级别，如果在跳转指令周围发生重新排序，我会感到惊讶，因为CPU无法知道分支是否是“子程序调用”，因此将返回到下一条指令。如果发生“非常规”跳跃，执行乱序将导致严重错误的行为。

是否可以从另一个线程观察部分构造的对象？

3 个答案: