class MyClass
{
    private readonly int a;
    private int b;

    public MyClass(int a,int b) { this.a = a; this.b = b; }

    public int A { get { return a; } }
    public int B { get { return b; } }
}

MyClass value = null;
Task.Run(() => {
    while (true) { value = new MyClass(1,1); Thread.Sleep(10); }
});
while (true)
{
    MyClass result = value;
    if (result != null && (result.A != 1 || result.B != 1)) { 
        throw new Exception(); 
    }
    Thread.Sleep(10);
}

写入的代码将从CLR2.0开始工作,因为CLR2.0内存模型保证所有存储都具有发布语义. @H_403_4@发布语义：确保在栅栏之前没有加载或存储
将围栏后移动.之后的说明可能还会发生
围栏(取自CPOW第512页).

@H_403_4@这意味着在引用类引用后,构造函数初始化不能被移动.

@H_403_4@乔·达菲在article about the very same subject年提到这一点.

@H_403_4@Rule 2: All stores have release semantics,i.e. no load or store may
move after one.

@H_403_4@Vance morrison的article here也证实了这一点(Section Technique 4：Lazy Initialization).

@H_403_4@Like all techniques that remove read locks,the code in Figure 7
relies on strong write ordering. For example,this code would be
incorrect in the ECMA memory model unless myValue was made volatile
because the writes that initialize the LazyInitClass instance might be
delayed until after the write to myValue,allowing the client of
GetValue to read the uninitialized state. In the .NET Framework 2.0
model,the code works without volatile declarations.

@H_403_4@写入保证按照从CLR 2.0开始的顺序发生.它没有在ECMA标准中指定,只是CLR的微软实现给了这个保证.如果您在CLR 1.0或CLR的任何其他实现中运行此代码,您的代码可能会中断.

@H_403_4@这个变化背后的故事是：(从CPOW第516页)

@H_403_4@When the CLR 2.0 was ported to IA64,its initial development had
happened on X86 processors,and so it was poorly equipped to deal with
arbitrary store reordering (as permitted by IA64) . The same was true
of most code written to target .NET by nonMicrosoft developers
targeting Windows

@H_403_4@The result was that a lot of code in the framework broke when run on
IA64,particularly code having to do with the infamous double-checked
locking pattern that suddenly didn’t work properly. We’ll examine this
in the context of the pattern later in this chapter. But in summary,
if stores can pass other stores,consider this: a thread might
initialize a private object’s fields and then publish a reference to
it in a shared location; because stores can move around,another
thread might be able to see the reference to the object,read it,and
yet see the fields while they are still i n an uninitialized state.
Not only did this impact existing code,it could violate type system
properties such as initonly fields.

@H_403_4@So the CLR architects made a decision to strengthen 2.0 by emitting
all stores on IA64 as release fences. This gave all CLR programs
stronger memory model behavior. This ensures that programmers needn’ t
have to worry about subtle race conditions that would only manifest in
practice on an obscure,rarely used and expensive architecture.

@H_403_4@注意Joe duffy说,他们通过将IA64上的所有商店作为释放栅栏来加强2.0,这并不意味着其他处理器可以重新排序.其他处理器本身固有的保证了商店(商店之后的商店)将不被重新排序.所以CLR不需要明确的保证这一点.