Checking for null before event dispatching… thread safe?

by

As you point out, where multiple threads can access SomeEvent simultaneously, one thread could check whether SomeEventis null and determine that it isn’t. Just after doing so, another thread could remove the last registered delegate from SomeEvent. When the first thread attempts to raise SomeEvent, an exception will be thrown. A reasonable way to avoid this scenario is: 

protected virtual void OnSomeEvent(EventArgs args) 
{
    EventHandler ev = SomeEvent;
    if (ev != null) ev(this, args);
}

This works because whenever a delegate is added to or removed from an event using the default implementations of the add and remove accessors, the Delegate.Combine and Delegate.Remove static methods are used. Each of these methods returns a new instance of a delegate, rather than modifying the one passed to it.

In addition, assignment of an object reference in .NET is atomic, and the default implementations of the add and remove event accessors are synchronised. So the code above succeeds by first copying the multicast delegate from the event to a temporary variable. Any changes to SomeEvent after this point will not affect the copy you’ve made and stored. Thus you can now safely test whether any delegates were registered and subsequently invoke them.

Note that this solution solves one race problem, namely that of an event handler being null when it’s invoked. It doesn’t handle the problem where an event handler is defunct when it’s invoked, or an event handler subscribes after the copy is taken.

For example, if an event handler depends on state that’s destroyed as soon as the handler is un-subscribed, then this solution might invoke code that cannot run properly. See Eric Lippert’s excellent blog entry for more details. Also, see this StackOverflow question and answers.

EDIT: If you’re using C# 6.0, then Krzysztof’s answer looks like a good way to go.

More Related Contents:

  1. C# Events and Thread Safety
  2. BackgroundWorker RunWorkerCompleted Event
  3. Cleanest Way to Invoke Cross-Thread Events
  4. Event handlers not thread safe? [duplicate]
  5. Avoiding the woes of Invoke/BeginInvoke in cross-thread WinForm event handling?
  6. Return a value from an Event — is there a Good Practice for this?
  7. Task vs Thread differences [duplicate]
  8. How to remove a lambda event handler [duplicate]
  9. What is the difference between await Task and Task.Result?
  10. Updating GUI (WPF) using a different thread
  11. ‘using’ statement vs ‘try finally’
  12. Thread.Sleep for less than 1 millisecond
  13. What is the impact of Thread.Sleep(1) in C#?
  14. The current SynchronizationContext may not be used as a TaskScheduler
  15. STAThread and multithreading
  16. Spawn Multiple Threads for work then wait until all finished
  17. c# working with Entity Framework in a multi threaded server
  18. How to terminate a thread in C#?
  19. Removing the delay after KeyDown event?
  20. Thread safe collections in .NET
  21. How to correctly read an Interlocked.Increment’ed int field?
  22. Is it safe to use a boolean flag to stop a thread from running in C#
  23. ConcurrentDictionary Pitfall – Are delegates factories from GetOrAdd and AddOrUpdate synchronized?
  24. Thread safety on readonly static field initialisation
  25. How to subscribe to other class’ events in C#?
  26. Synchronous implementation of interface that returns Task
  27. Populating a DataGridView with Text and ProgressBars
  28. How to properly parallelise job heavily relying on I/O
  29. Does MessageBox.Show() automatically marshall to the UI Thread?
  30. When exactly does .NET Monitor go to kernel-mode?

Leave a Comment