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