26

If I am using EventWaitHandle (or AutoResetEvent, ManualResetEvent) to synchronise between threads then do I need to call the Close() or Dispose() methods on that event handle when I am done with it?

EventWaitHandle inherits from WaitHandle, which implements IDisposable. And FxCop complains if I don't implement IDisposable on any class that contains an EventWaitHandle. So this suggests that I do need to call it.

However none of these MSDN usage examples call Dispose() or Close():

http://msdn.microsoft.com/en-us/library/system.threading.eventwaithandle(VS.80).aspx http://msdn.microsoft.com/en-us/library/system.threading.manualresetevent(VS.80).aspx http://msdn.microsoft.com/en-us/library/system.threading.autoresetevent(VS.80).aspx

Is this just an example of Microsoft ignoring their own advice?

GrahamS
  • 9,980
  • 9
  • 49
  • 63

5 Answers5

27

The disposable resource of an EventWaitHandle is actually a SafeHandle (wrapped in a SafeWaitHandle). SafeHandle implements a finalizer, which eventually makes sure the necessary resource is release, so it should be safe to let the garbage collector / finalizer thread handle it in this case.

However, it is always a good idea to explicitly call Dispose() when the resource is no longer needed.

The threading chapter in C# 3.0 in a Nutshell states

This practice is (arguably) acceptable with wait handles because they have a light OS burden (asynchronous delegates rely on exactly this mechanism to release their IAsyncResult's wait handle).

Brian Rasmussen
  • 114,645
  • 34
  • 221
  • 317
  • I'd argue that letting the GC collect it is quite undesirable. Leaving the work to the Finalizer thread is just bad practice. There is but a single finalizer thread and causing it to do more than it really should is not good. If the thread gets blocked, your app is hung. If an exception is thrown on the finalizer thread, your AppDomain crashes. Having the proper dispose pattern guarantees that GC.SuppressFinalize() is called thus suppressing finalization of this object. I have an example of implementing IDisposable - http://dave-black.blogspot.com/2011/03/how-do-you-properly-implement.html – Dave Black Aug 27 '14 at 18:02
  • I agree and that's why I state that you should explicitly call `Dispose`. – Brian Rasmussen Aug 27 '14 at 18:03
6

You need to dispose them explicitly. Close() is more appropriate for them as it does call Dispose().

Mohit Chakraborty
  • 1,253
  • 8
  • 8
2

Class definitions from MSDN:

public class EventWaitHandle : WaitHandle
public abstract class WaitHandle : MarshalByRefObject, IDisposable

So yes you must as WaitHandle is IDisposable. FxCop would find this as a rule violation if you didn't.

Peter Drier
  • 1,327
  • 1
  • 11
  • 11
  • Thanks Peter, but why don't the MSDN usage examples call Close() or Dispose()? Is this just Microsoft not following their own advice? – GrahamS Mar 19 '09 at 09:46
  • 1
    I'd guess it's 50% not following their own advice, and 50% trying to keep the examples as brief as possible.. with a side dish of the folks writing the examples (not the core sdk developers) not knowing better. – Peter Drier Mar 19 '09 at 16:47
  • @PeterDrier The examples use static wait handles. – Lunar Whisper Jan 23 '19 at 11:03
0

Close method disposes it internally.

Ajeet Malviya
  • 784
  • 1
  • 5
  • 9
0

MSDN says:

Always call Close or Dispose() before you release your last reference to the WaitHandle. Otherwise, the resources it is using will not be freed.

So, as they inherit WaitHandle, in my opinion, you should dispose the EventWaitHandle (or AutoResetEvent, ManualResetEvent) too

Alexandr Sahatir
  • 21
  • 5