ManualResetEvent and AutoResetEvent in Thread

These two type inherit are derived from System.Threading.EventWaitHandle and add no functionality to it. Using them is equivalent to using EventWaitHandle with different constructor parameters; first parameter defines if the reset done automatically or not. So let's consider just this class, see http://msdn.microsoft.com/en-us/library/system.threading.eventwaithandle.aspx[^].

Let's look at the constructor and the code sample at the end of this page: http://msdn.microsoft.com/en-us/library/csc3y90t.aspx[^].

Please locate this string in the code sample: "ewh.WaitOne();".

This is a blocking call. The event wait handle has two states: signaled, one can put it to this state by calling ewh.Set() and non-signaled, one can put it to this state by calling ewh.Reset(). The blocking call shown above puts a calling thread in a wait state by OS; the thread is switched off, use zero CPU time and is never scheduled back to execution until it is waken up. It can be waken by by timeout (if any) and also by some other thread which can call Thread.Abort or signal the ewh.Set().

When a thread is waken up by the event wait handle, what happens to the ehw state? It depends on the EventResetMode passed to this object's constructor (please see the constructor signature in the article referenced above). If this mode is EventResetMode.ManualReset, its state remains signaled, which effects the behavior of this or another thread calling ewh.WaitOne();.

If this mode is EventResetMode.AutoReset, it is automatically gets the non-signaled state when the thread waiting in ewh.WaitOne(); is atomic way. "Atomic" if very important here: you cannot possibly simulate this behavior on 100% reliable way using manual reset. Auto-reset is designed to pass one and only one thread and keep all other threads waiting, which is very valuable behavior is some techniques.

—SA