内存重新排序会导致 C# 访问未分配的内存吗？
Can memory reordering cause C# to access unallocated memory?
据我了解，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.
我一直对 "partially constructed instance" 的含义感到困惑。假设 .NET 运行时在分配时清除内存而不是垃圾收集 (discussion), does this mean that the other thread might read memory that still contains data from garbage-collected objects (like 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。但是，是否有可能第二个线程在buffer 数组的内存初始化为0之前读取了对buffer 的新引用，并输出了一些其他的任意字符串？
我们不要在这里埋头苦干：你的问题的答案是不，你永远不会观察到 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 是非空的，那么 you 有责任确保这个不变量总是被观察到是真的。如果以某种方式 this 被两个线程观察到，那么其中一个线程可能会观察到不变量被违反。
据我了解，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.
我一直对 "partially constructed instance" 的含义感到困惑。假设 .NET 运行时在分配时清除内存而不是垃圾收集 (discussion), does this mean that the other thread might read memory that still contains data from garbage-collected objects (like 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。但是，是否有可能第二个线程在buffer 数组的内存初始化为0之前读取了对buffer 的新引用，并输出了一些其他的任意字符串？
我们不要在这里埋头苦干：你的问题的答案是不，你永远不会观察到 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 是非空的，那么 you 有责任确保这个不变量总是被观察到是真的。如果以某种方式 this 被两个线程观察到，那么其中一个线程可能会观察到不变量被违反。