27

我经常听说在 .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，并且（在大多数情况下）继续我的工作？

4

3 回答 3

10

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

这取决于您所指的型号。

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

  • ECMA 规范有一个宽松的模型，其中写入不提供此保证。
  • 有人在某处引用过 Microsoft 提供的 CLR 实现通过使写入具有释放栅栏语义来增强模型。
  • x86 和 x64 架构通过设置写入释放栅栏和读取获取栅栏来加强模型。

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

我们应该明确列出正在使用的内存模型层。

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

这是否意味着即使没有显式的内存屏障或锁，也不可能在与创建对象不同的线程上观察到部分构造的对象（仅考虑引用类型）？

是（合格）：如果应用程序运行的环境足够模糊，那么可能会从另一个线程观察到部分构造的实例。这就是为什么不使用volatile. 然而，实际上，我怀疑您是否会遇到这种情况，主要是因为 Microsoft 的 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 规范中写入没有释放栅栏语义，因此其他读取和写入可以“浮动”超过分配以person产生以下有效的指令序列。

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

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

于 2011-12-02T16:11:47.450 回答
1

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

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

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

于 2011-12-02T20:53:09.497 回答
1

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

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

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

于 2011-12-02T21:11:38.567 回答