C# 事件和线程安全

我一直在使用这种设计模式来确保事件处理程序在取消订阅后不会被执行。到目前为止，它运行得很好，尽管我还没有尝试过任何性能分析。

private readonly object eventMutex = new object();

private event EventHandler _onEvent = null;

public event EventHandler OnEvent
{
  add
  {
    lock(eventMutex)
    {
      _onEvent += value;
    }
  }

  remove
  {
    lock(eventMutex)
    {
      _onEvent -= value;
    }
  }

}

private void HandleEvent(EventArgs args)
{
  lock(eventMutex)
  {
    if (_onEvent != null)
      _onEvent(args);
  }
}

这些天，我主要使用 Mono for Android，当您在 Activity 发送到后台后尝试更新 View 时，Android 似乎不喜欢它。

这种做法并不是要强制执行特定的操作顺序。它实际上是关于避免空引用异常。

人们关心空引用异常而不是竞争条件的原因需要一些深入的心理学研究。我认为这与修复空引用问题要容易得多这一事实有关。一旦解决了这个问题，他们就会在代码上挂一个大大的“任务完成”横幅，然后解开飞行服的拉链。

注意：修复竞争条件可能涉及使用同步标志跟踪处理程序是否应该运行

所以我在这里聚会有点晚了。 :)

至于使用 null 而不是 null 对象模式来表示没有订阅者的事件，请考虑这种情况。您需要调用一个事件，但构造对象 (EventArgs) 并非易事，而且在通常情况下，您的事件没有订阅者。如果您可以优化您的代码以检查您是否有任何订阅者，然后再提交处理工作以构造参数和调用事件，这对您将是有益的。

考虑到这一点，一个解决方案是说“嗯，零订阅者由 null 表示”。然后在执行昂贵的操作之前简单地执行空检查。我想另一种方法是在 Delegate 类型上使用 Count 属性，因此只有在 myDelegate.Count > 0 时才执行昂贵的操作。使用 Count 属性是一种很好的模式，可以解决原始问题允许优化，并且它还具有能够在不导致 NullReferenceException 的情况下被调用的良好属性。

但是请记住，由于委托是引用类型，因此它们可以为空。也许根本没有什么好的方法可以隐藏这个事实并仅支持事件的空对象模式，因此替代方案可能会迫使开发人员同时检查空订阅者和零订阅者。那将比现在的情况更丑陋。

注意：这是纯粹的猜测。我不涉及 .NET 语言或 CLR。

对于单线程应用程序，您是正确的，这不是问题。

但是，如果您正在制作一个公开事件的组件，则无法保证您的组件的使用者不会使用多线程，在这种情况下，您需要为最坏的情况做好准备。

使用空委托确实可以解决问题，但也会导致每次调用事件时性能受到影响，并且可能会产生 GC 影响。

您是对的，消费者尝试取消订阅以使这种情况发生，但如果他们通过临时副本，则考虑该消息已经在传输中。

如果你不使用临时变量，也不使用空委托，并且有人取消订阅，你会得到一个空引用异常，这是致命的，所以我认为这个成本是值得的。

我从来没有真正认为这是一个很大的问题，因为我通常只在我的可重用组件上的静态方法（等）中防止这种潜在的线程错误，并且我不制作静态事件。

我做错了吗？

在施工中连接您的所有活动，不要管它们。 Delegate 类的设计不可能正确处理任何其他用法，我将在本文的最后一段中解释。

首先，当您的事件处理程序必须已经就是否/如何响应通知做出同步决定时，尝试拦截事件通知是没有意义的。

任何可能被通知的事情，都应该被通知。如果您的事件处理程序正确处理通知（即他们可以访问权威的应用程序状态并仅在适当时响应），那么随时通知他们并相信他们会正确响应就可以了。

唯一不应该通知处理程序事件发生的情况是事件实际上没有发生！因此，如果您不希望通知处理程序，请停止生成事件（即禁用控件或首先负责检测和使事件存在的任何东西）。

老实说，我认为 Delegate 类是无法挽救的。向 MulticastDelegate 的合并/转换是一个巨大的错误，因为它有效地将事件的（有用的）定义从发生在某个时刻的事情变成了在一段时间内发生的事情。这种变化需要一种同步机制，可以在逻辑上将其折叠回单个瞬间，但 MulticastDelegate 缺少任何此类机制。同步应该包括事件发生的整个时间跨度或瞬间，以便一旦应用程序做出开始处理事件的同步决定，它就会完全（事务性地）完成处理。使用 MulticastDelegate/Delegate 混合类的黑盒，这几乎是不可能的，因此请坚持使用单订阅者和/或实现您自己的 MulticastDelegate 类型，它具有可以在处理程序链运行时取出的同步句柄正在使用/修改。我推荐这个，因为替代方案是在所有处理程序中冗余地实现同步/事务完整性，这将是荒谬/不必要的复杂。

请在此处查看：http://www.danielfortunov.com/software/%24daniel_fortunovs_adventures_in_software_development/2009/04/23/net_event_invocation_thread_safety 这是正确的解决方案，应始终使用，而不是所有其他解决方法。

“您可以通过使用无操作匿名方法对其进行初始化来确保内部调用列表始终具有至少一个成员。因为没有外部方可以引用匿名方法，所以没有外部方可以删除该方法，因此委托永远不会为空” — 编程 .NET 组件，第 2 版，作者：Juval Löwy

public static event EventHandler<EventArgs> PreInitializedEvent = delegate { };  

public static void OnPreInitializedEvent(EventArgs e)  
{  
    // No check required - event will never be null because  
    // we have subscribed an empty anonymous delegate which  
    // can never be unsubscribed. (But causes some overhead.)  
    PreInitializedEvent(null, e);  
}  

我不相信这个问题仅限于 c#“事件”类型。消除这个限制，为什么不重新发明轮子并按照这些思路做点什么？

Raise event thread safely - best practice

能够在提升期间从任何线程订阅/取消订阅（竞争条件已删除）

+= 和 -= 在类级别的运算符重载。

通用调用者定义的委托

感谢您的有用讨论。我最近正在解决这个问题，并制作了以下课程，它有点慢，但可以避免调用已处置的对象。

这里的要点是即使引发事件也可以修改调用列表。

/// <summary>
/// Thread safe event invoker
/// </summary>
public sealed class ThreadSafeEventInvoker
{
    /// <summary>
    /// Dictionary of delegates
    /// </summary>
    readonly ConcurrentDictionary<Delegate, DelegateHolder> delegates = new ConcurrentDictionary<Delegate, DelegateHolder>();

    /// <summary>
    /// List of delegates to be called, we need it because it is relatevely easy to implement a loop with list
    /// modification inside of it
    /// </summary>
    readonly LinkedList<DelegateHolder> delegatesList = new LinkedList<DelegateHolder>();

    /// <summary>
    /// locker for delegates list
    /// </summary>
    private readonly ReaderWriterLockSlim listLocker = new ReaderWriterLockSlim();

    /// <summary>
    /// Add delegate to list
    /// </summary>
    /// <param name="value"></param>
    public void Add(Delegate value)
    {
        var holder = new DelegateHolder(value);
        if (!delegates.TryAdd(value, holder)) return;

        listLocker.EnterWriteLock();
        delegatesList.AddLast(holder);
        listLocker.ExitWriteLock();
    }

    /// <summary>
    /// Remove delegate from list
    /// </summary>
    /// <param name="value"></param>
    public void Remove(Delegate value)
    {
        DelegateHolder holder;
        if (!delegates.TryRemove(value, out holder)) return;

        Monitor.Enter(holder);
        holder.IsDeleted = true;
        Monitor.Exit(holder);
    }

    /// <summary>
    /// Raise an event
    /// </summary>
    /// <param name="args"></param>
    public void Raise(params object[] args)
    {
        DelegateHolder holder = null;

        try
        {
            // get root element
            listLocker.EnterReadLock();
            var cursor = delegatesList.First;
            listLocker.ExitReadLock();

            while (cursor != null)
            {
                // get its value and a next node
                listLocker.EnterReadLock();
                holder = cursor.Value;
                var next = cursor.Next;
                listLocker.ExitReadLock();

                // lock holder and invoke if it is not removed
                Monitor.Enter(holder);
                if (!holder.IsDeleted)
                    holder.Action.DynamicInvoke(args);
                else if (!holder.IsDeletedFromList)
                {
                    listLocker.EnterWriteLock();
                    delegatesList.Remove(cursor);
                    holder.IsDeletedFromList = true;
                    listLocker.ExitWriteLock();
                }
                Monitor.Exit(holder);

                cursor = next;
            }
        }
        catch
        {
            // clean up
            if (listLocker.IsReadLockHeld)
                listLocker.ExitReadLock();
            if (listLocker.IsWriteLockHeld)
                listLocker.ExitWriteLock();
            if (holder != null && Monitor.IsEntered(holder))
                Monitor.Exit(holder);

            throw;
        }
    }

    /// <summary>
    /// helper class
    /// </summary>
    class DelegateHolder
    {
        /// <summary>
        /// delegate to call
        /// </summary>
        public Delegate Action { get; private set; }

        /// <summary>
        /// flag shows if this delegate removed from list of calls
        /// </summary>
        public bool IsDeleted { get; set; }

        /// <summary>
        /// flag shows if this instance was removed from all lists
        /// </summary>
        public bool IsDeletedFromList { get; set; }

        /// <summary>
        /// Constuctor
        /// </summary>
        /// <param name="d"></param>
        public DelegateHolder(Delegate d)
        {
            Action = d;
        }
    }
}

用法是：

    private readonly ThreadSafeEventInvoker someEventWrapper = new ThreadSafeEventInvoker();
    public event Action SomeEvent
    {
        add { someEventWrapper.Add(value); }
        remove { someEventWrapper.Remove(value); }
    }

    public void RaiseSomeEvent()
    {
        someEventWrapper.Raise();
    }

测试

我以以下方式对其进行了测试。我有一个线程可以创建和销毁这样的对象：

var objects = Enumerable.Range(0, 1000).Select(x => new Bar(foo)).ToList();
Thread.Sleep(10);
objects.ForEach(x => x.Dispose());

在 Bar（侦听器对象）构造函数中，我订阅了 SomeEvent（如上所示实现）并在 Dispose 中取消订阅：

    public Bar(Foo foo)
    {
        this.foo = foo;
        foo.SomeEvent += Handler;
    }

    public void Handler()
    {
        if (disposed)
            Console.WriteLine("Handler is called after object was disposed!");
    }

    public void Dispose()
    {
        foo.SomeEvent -= Handler;
        disposed = true;
    }

我也有几个线程在循环中引发事件。

所有这些操作都是同时执行的：创建和销毁许多侦听器，同时触发事件。

如果有竞争条件，我应该在控制台中看到一条消息，但它是空的。但是如果我像往常一样使用 clr 事件，我会看到它充满了警告消息。因此，我可以得出结论，可以在 c# 中实现线程安全事件。

你怎么看？