You are badly misusing the event wait handle objects. These events are used only to notify the thread in a wait state, to wake it up. Actually, this is not an "event" in the sense of something you can "send" and "receive", this is a way to throttle execution of some thread without any waste of CPU time (as it happens with spin wait): the thread waiting for the event wait handler object is switched out and is not scheduled back to execution until it is waken up by the event wait handler set by another thread. It also can be used for thread synchronization, to make one thread waiting for another thread to complete some part of work. As all blocking call, it should be used with great consideration and theoretical calculations of the application lifetime.
Also, manual reset right after waking up (or almost, as in your case) can be considered as another abuse. (But it depends on what you try to achieve.) You could use
System.Threading.AutoResetEvent
. The functionality is no the same as in your seemingly "simulated" auto reset. It is impossible to guarantee simulation
AutoResetEvent
's reset with
ManualResetEvent
reset: auto resetting mechanism guarantees that exactly one thread at a time is passed through the point when the thread is waken up; the second thread will be always blocked again.
Your static class-factory methods are totally redundant: if you want to choose auto or manual reset depending on condition, you could use the base class
System.Threading.EventWaitHandle
and control the type of reset using its constructor, one of the constructors using
EventResetMode
argument:
https://msdn.microsoft.com/en-us/library/system.threading.eventwaithandle%28v=vs.110%29.aspx.
Your
RaiseEvent
method is correct (however, it's not clear why writing a separate method, but it's OK), but you did not show where you called it. It will really wake up the thread blocked at the wait for the event wait handler. It all depends on when you call it. But main thing is: there is no such thing as "receive" this kind of event.
See also my past answers on this topic and on the purpose of these classes:
ManualResetEvent and AutoResetEvent in Thread,
pause running thread,
Making Code Thread Safe.,
Running exactly one job/thread/process in webservice that will never get terminated (asp.net)..
Now, these classes are mostly used for thread synchronization for the threads of the same process. For IPC, there are many different facilities. I would like to mention one which is often forgotten: sockets. Remember that, historically, sockets have been developed purely as IPC facility, only later used for networking. This is still a very good and flexible IPC tool. Please see:
https://msdn.microsoft.com/en-us/library/system.net.sockets%28v=vs.110%29.aspx.
—SA