Question

I have a weird deadlock situation. After attached visual studio. I saw 3 threads that stuck.

1. Thread 1:

   if (SomeEvent != null)
      SomeEvent(this, new SomeArg) --> Stuck
   

2. Thread 2:

   if (SomeEvent2 != null)
       SomeEvent2(this, new SomeArg2) --> Stuck
   

3. Main Thread:

   public object (Delegate method, object[] args)
   {
      ...
      SynchronizationContext.Send(delegate(object state))
      {
          ...
          method.DynamicInvoke(args); --> Stuck
      }
   }
   

These three threads are stuck, and when I check their call stacks, I wasn’t able to find any shared resource, like lock(), or Monitor.Wait(). I believe they all stuck on external calls.

In addition, I can’t tell what method.DynamicInvoke(args) is doing and what this method supposed to be.

The only one thing I found is that the attached event handlers may cause deadlock. However, since VS has show me this is where it stucks, and not at the event handler code. I think it may be something else.

In term of the application, I know this is a race condition, because the application was trying to perform loading and unload data around the same time, so this problem is rather hard to reproduce.

My question are:

1. Why would .NET thread hangs when raising an event, is it even possible?
2. Does the Main UI thread need to be used when raising an event?
3. If indeed it is possible for the event raising to deadlock, how should I prevent this?

Thanks

Answer 1

1. Is it possible for a thread to hang when raising an event? Yes, it is. The thread of execution doesn’t return from the raising of the event until the event handlers are finished. Event handlers could be anything, and therefore they can hang. If an event handler hangs, the event-raising thread hangs.

2. No, the Main UI thread does not need to be used to raise events. Any thread can raise events.

3. Event raising isn’t especially prone to deadlocks, but it isn’t immune to it either. When you raise an event the thread you are on executes whatever code has been registered as event handlers. That code isn’t special. It’s just code executing on the same thread that raised the event. It can deadlock or not for all the same reasons any code can deadlock.

The point is that there isn’t anything particularly magical about how the code for events and event handlers gets executed. While I’m simplifying to the point that I’m almost certainly wrong, the basics are that events are just multicast delegates that are available to have elements added to and removed from their invocation list publicly, but all other forms access are private. There is nothing about events that is thread related. Using events wouldn’t impact the existence of a deadlock as compared to executing the same code in the event handlers some other way.