This is admittedly an unusual question; I would never recommend replacing a boolean with a ManualResetEvent in typical .NET development. In this case, I already need a ManualResetEvent to indicate connection status to another thread; given that, it occurs to me that the use of a boolean with the same semantic meaning is redundant.
OK, specifics: I have a worker thread that should process messages when the following conditions are true:
- “Client” connected
- “Recipient” connected
The “client” and “recipient” connections are TCP sockets which other threads are monitoring; when either connection status changes, the corresponding WaitHandle will be set (Connected) or reset (Disconnected).
Originally, I had a boolean indicated the connection state (for UI). Now that I am using WaitHandles to signal the worker thread, it seems advantageous to eliminate the boolean state variables entirely and just use the WaitHandles.
waitEvent.WaitOne( 0 )
returns the state of the handle without blocking, making it functionally identical to testing a boolean value (with the added advantage of thread-safe operation).
So, given that I am already going to be using the WaitHandles, and I don’t like the idea of maintaining the state (same semantic meaning) into two different variables, is there any reason why I can’t just use the WaitHandles? The most significant counter-argument I can think of is runtime performance: time to test a boolean vs. time to test the WaitHandle; but I don’t think performance will be that significantly affected.
Am I missing anything significant here?
Thanks!
The benefit of just using the
ManualResetEventare that you only have one variable tracking the same state. However, as you mentioned, there will be overhead to read the state back out.You have to ask if that overhead is significant enough to justify tracking the same state in two places and risk them becoming out-of-sync.