此通用模式中是否存在用于防止空引用异常的竞争条件？

Question

我问了这个问题，得到了这个有趣（也有点令人不安）的答案。

Daniel在他的回答中指出（除非我读错了），ECMA-335 CLI规范允许编译器从以下方法生成引发NullReferenceException的代码。

class MyClass {
    private Action _Callback;
    public Action Callback { 
        get { return _Callback; }
        set { _Callback = value; }
    }
    public void DoCallback() {
        Action local;
        local = Callback;
        if (local == null)
            local = new Action(() => { });
        local();
    }
}

他说，为了保证不抛出NullReector ceException，的易失性关键字应该在_Callback上使用，或者lock应该在local=Callback；行周围使用。

有人能证实这一点吗？如果这是真的，Mono和。NET编译器有关此问题的信息？

编辑此处是标准的链接。

更新我认为这是规范（12.6.4）的相关部分：

CLI的一致性实现可以使用任何技术自由执行程序，这些技术可以保证在单个执行线程内，线程生成的副作用和异常按照CIL指定的顺序可见。为此，只有易失性操作（包括易失性读取）才构成可见的副作用。（请注意，虽然只有易失性操作构成可见的副作用，但易失性操作也会影响非易失性引用的可见性。）挥发性操作在§12.6.7中有规定。对于另一个线程注入到线程中的异常，没有排序保证（此类异常有时称为“异步异常”（例如，System.Threading.ThreadAbortException）。

[理由：优化编译器可以自由地对副作用和同步异常进行重新排序，只要这种重新排序不会改变任何可观察到的程序行为。结束理由]

[注意：允许CLI的实现使用优化编译器，例如，将CIL转换为本机机器代码，前提是编译器保持（在每个执行线程中）相同的副作用和同步异常顺序。

所以我很好奇，这条语句是否允许编译器优化回调属性（访问一个简单字段）和局部变量以生成以下内容，这些内容在单个执行线程中具有相同的行为：

if (_Callback != null) _Callback();
else new Action(() => { })();

关于volatile关键字的12.6.7部分似乎为希望避免优化的程序员提供了一个解决方案：

易失性读取具有“获取语义学”，这意味着读取保证发生在CIL指令序列中读取指令之后发生的任何内存引用之前。易失性写入具有“释放语义学”，这意味着写入保证发生在CIL指令序列中写入指令之前的任何内存引用之后。符合CLI的实现应保证易失性操作的这种语义学。这确保所有线程都将观察到任何其他线程按照它们执行的顺序执行的易失性写入。但是符合的实现不需要提供从所有执行线程中看到的易失性写入的单一总顺序。将CIL转换为本机代码的优化编译器不得删除任何易失性操作，也不得将多个易失性操作合并为单个操作。

Answer 1

此代码不会引发null引用异常。这是线程安全的：

public void DoCallback() {
    Action local;
    local = Callback;
    if (local == null)
        local = new Action(() => { });
    local();
}

这个函数是线程安全的，并且不能在回调时抛出NullReferenceException，原因是它在执行null检查/调用之前正在复制到局部变量。即使在null检查后将原始回调设置为null，局部变量仍然有效。

然而，以下是一个不同的故事：

public void DoCallbackIfElse() {
    if (null != Callback) Callback();
    else new Action(() => { })();
}

在本例中，它查看的是一个公共变量，回调可以在if（null！=回调）之后更改为null，这将在回调（）上引发异常

Answer 2

在CLR中通过C#（第。

[T] 编译器可以对他的代码进行优化，以完全删除局部[…]变量。如果发生这种情况，此版本的代码与[直接引用事件/回调两次的版本]相同，因此仍然可能出现NullReferenceException。

里克特建议使用联锁。比较交换

public void DoCallback() 
{
    Action local = Interlocked.CompareExchange(ref _Callback, null, null);
    if (local != null)
        local();
}

然而，里希特承认微软的实时（JIT）编译器并没有优化掉局部变量；而且，虽然从理论上讲，这可能会改变，但几乎肯定永远不会改变，因为这将导致太多应用程序因此而中断。

这个问题已经在“允许的C#编译器优化局部变量和从内存中重新获取值”中详细提出和回答。请务必阅读xanatox的答案和它引用的“了解多线程应用程序中低锁技术的影响”文章。既然你特别问到了Mono，你应该注意参考的“[Mono-dev]内存模型？”邮件列表消息：

现在，我们提供了松散的语义，接近您正在运行的体系结构支持的ecma。