c# - 内存重新排序会导致 C# 访问未分配的内存吗？

Question

据我了解，C# 是一种安全语言，不允许访问未分配的内存，除非通过 unsafe 关键字。但是，它的内存模型允许在线程之间存在不同步访问时重新排序。这会导致竞争危险，其中对新实例的引用似乎在实例完全初始化之前可用于竞争线程，并且是双重检查锁定的一个众所周知的问题。 Chris Brumme(来自 CLR 团队)在他们的 Memory Model 中解释了这一点文章:

Consider the standard double-locking protocol:

if (a == null)
{
    lock(obj)
    {
        if (a == null) 
            a = new A();
    }
}

This is a common technique for avoiding a lock on the read of ‘a’ in the typical case. It works just fine on X86. But it would be broken by a legal but weak implementation of the ECMA CLI spec. It’s true that, according to the ECMA spec, acquiring a lock has acquire semantics and releasing a lock has release semantics.

However, we have to assume that a series of stores have taken place during construction of ‘a’. Those stores can be arbitrarily reordered, including the possibility of delaying them until after the publishing store which assigns the new object to ‘a’. At that point, there is a small window before the store.release implied by leaving the lock. Inside that window, other CPUs can navigate through the reference ‘a’ and see a partially constructed instance.

我一直对“部分构造的实例”的含义感到困惑。假设 .NET 运行时在分配时清除内存而不是垃圾回收 (discussion)，这是否意味着另一个线程可能读取仍然包含来自垃圾回收对象(如 what happens in unsafe languages)的数据的内存？

考虑以下具体示例:

byte[] buffer = new byte[2];

Parallel.Invoke(
    () => buffer = new byte[4],
    () => Console.WriteLine(BitConverter.ToString(buffer)));

上面有一个竞争条件；输出将是 00-00 或 00-00-00-00。但是，第二个线程是否有可能在数组的内存初始化为 0 之前读取对 buffer 的新引用 ，并输出一些其他任意字符串？

Answer 1

我们不要在这里埋头苦干:您问题的答案是不，您永远不会观察到 CLR 2.0 内存模型中的内存预分配状态。

我现在将解决您的几个非中心点。

It is my understanding that C# is a safe language and doesn't allow one to access unallocated memory, other than through the unsafe keyword.

这或多或少是正确的。有一些机制可以在不使用 unsafe 的情况下访问伪造的内存。 -- 显然是通过非托管代码，或者通过滥用结构布局。但总的来说，是的，C# 是内存安全的。

However, its memory model allows reordering when there is unsynchronized access between threads.

同样，这或多或少是正确的。更好的思考方式是，C# 允许在受某些限制的情况下，在重新排序对单线程程序不可见的任何点 重新排序。这些约束包括在某些情况下引入获取和释放语义，以及在某些关键点保留某些副作用。

Chris Brumme (from the CLR team) ...

Chris 已故伟大的文章是瑰宝，对 CLR 的早期提供了大量的见解，但我注意到自 2003 年撰写该文章以来，内存模型得到了一些加强，特别是关于您提出的问题。

Chris 是对的，双重检查锁定非常危险。有一种在 C# 中进行双重检查锁定的正确方法，当你片刻偏离它时，即使轻微，你也会陷入可怕的错误之中，这些错误只会重现在弱内存模型硬件上。

does this mean that the other thread might read memory that still contains data from garbage-collected objects

我认为您的问题不是专门针对 Chris 所描述的旧的弱 ECMA 内存模型，而是关于今天实际做出的保证。

重新排序不可能公开对象的先前状态。您可以保证，当您读取一个新分配的对象时，它的字段全为零。

这是因为所有写入在当前内存模型中都具有释放语义；详情请看:

http://joeduffyblog.com/2007/11/10/clr-20-memory-model/

将内存初始化为零的写入相对于稍后的读取不会及时向前移动。

I've always been confused by "partially constructed objects"

Joe 在这里讨论:http://joeduffyblog.com/2010/06/27/on-partiallyconstructed-objects/

这里关心的不是我们可能会看到对象的预分配状态。相反，这里的问题是一个线程可能会看到一个对象而构造函数仍在另一个线程上运行。

确实，构造器和终结器有可能并发运行，这太奇怪了!由于这个原因，终结器很难正确编写。

换句话说:CLR 向您保证它自己的不变量将被保留。 CLR 的一个不变量是观察到新分配的内存被清零，因此将保留不变量。

但是 CLR 不负责保存您的不变量!如果您有一个构造函数来保证该字段 x是true当且仅当 y是非空的，那么你有责任确保这个不变量总是被观察到为真。如果以某种方式this被两个线程观察到，那么其中一个线程可能会观察到不变量被违反。