c# - 编写事件访问器时的多线程问题

Question

我正在寻找有关 Microsoft 为什么建议在编写事件访问器语法时锁定对象的其他信息。微软的代码示例如下所示，推荐链接。

我理解关于锁定一段代码以控制对它的多线程访问的一般概念，但是我正在寻找在 Microsoft 示例的上下文中编写自定义事件访问器逻辑时这些问题发挥作用的具体原因显示。

The following example shows how to implement custom add and remove event accessors. Although you can substitute any code inside the accessors, we recommend that you lock the event before you add or remove a new event handler method.

event EventHandler IDrawingObject.OnDraw
    {
        add
        {
            lock (PreDrawEvent)
            {
                PreDrawEvent += value;
            }
        }
        remove
        {
            lock (PreDrawEvent)
            {
                PreDrawEvent -= value;
            }
        }
    }

~通过https://msdn.microsoft.com/en-us/library/bb882534.aspx?f=255&MSPPError=-2147217396

Answer 1

只有 MSDN 文章的作者才能就文章的措辞为您提供明确的答案。

但是:在我看来，这个建议的主要原因是代码几乎总是使用编译器提供的事件访问器方法。这些一直旨在实现 100% 线程安全，并且最近对编译器进行了更改(我认为是从 C# 4 开始的，但我不太记得了)，它们实际上是。

我认为，使默认实现线程安全的原因是不言自明的:这样做的成本相当低，而且事件访问器方法中对线程安全的需求非常频繁，以至于迫使开发人员实现自己的线程安全访问器每次都需要线程安全是不合理的。

因此，鉴于默认实现是线程安全的，这意味着事件的消费者(他们通常无法访问事件的源代码)将习惯于假设事件访问者是始终线程安全。违反此假设可能会导致代码中出现错误。

底线:如果您 100% 确定您的事件只会在单个线程中被访问，或者至少以线程安全的方式访问，您可以在不向访问器方法添加显式线程安全的情况下逃脱。问题是达到这种 100% 的确定性是可疑的；几乎不可能预测一段特定的代码将如何使用，尤其是在谈论的更远的 future 。

代码可以存在很长时间。最好确保它可以处理抛给它的东西，尤其是当代码的 future 客户有充分的理由认为代码可以处理它时。

顺便说一句:虽然 MSDN 显示锁定事件字段本身，但这对我来说似乎有问题。一旦字段被更新，任何当前持有的锁都不会阻止后续执行的代码进入锁，即使锁本身还没有退出。由于对字段的读写顺序不正确，某些平台上可能存在字段可见性问题；这可能会导致两个随后执行的线程看到不同的锁值，然后同时进入 protected 部分。

不要介意使用公开可用值进行锁定的更普遍的问题。关于该特定主题存在一些争论，但我更倾向于只使用私有(private)值进行锁定。 IE。不要使用事件字段的当前值进行锁定(因为它是可变的)并且不要使用 this 进行锁定(因为它是公开的)。