how to read status of AutoResetEvent?

  • Thread starter Thread starter buu
  • Start date Start date
B

buu

so, I have a private object as system.threading.AutoResetEvent, and I would
like to read it's current status.

currently I have an another boolean object wich I update together with an
AutoResetEvent, but I don't think it's the best practice....
 
buu said:
so, I have a private object as system.threading.AutoResetEvent, and I would
like to read it's current status.
Click to expand...
You can't, for a good reason: it couldn't possibly be made thread-safe.
currently I have an another boolean object wich I update together with an
AutoResetEvent, but I don't think it's the best practice....
Click to expand...
Actually, it is, but only if you use locks to make this access thread-safe.

In many cases, using a monitor is more flexible and easier to get right than
using an AutoResetEvent. You can use Monitor.Pulse() and Monitor.Wait() to
let threads notify each other in much the same way.

bool conditionMet;
object conditionMonitor = new object();

lock (conditionMonitor ) {
if (!conditionMet) Monitor.Wait(conditionMonitor);
// conditionMet == true and no other thread is in this monitor
}

....

lock (conditionMonitor) {
conditionMet = true;
Monitor.Pulse(conditionMonitor);
}
 
so, I have a private object as system.threading.AutoResetEvent, and I would
like to read it's current status.
Click to expand...

Couldn't you do a WaitOne on it for 1 millisecond?
 
AMercer said:
Couldn't you do a WaitOne on it for 1 millisecond?
Click to expand...

This is a bad idea. First, it changes the state of the event if it's
signaled. You can set the event again, of course, but only if you take care
not to wait for it immediately again afterwards to "check" the status. In
the worst case you'd have to take over the responsibilities of the other
waiting threads.

Second, if the event is not signaled, waiting is likely to invoke a context
switch, which will probably take more than 1 millisecond, so this technique
doesn't scale. In fact, it's bizarrely more costly than checking a
self-maintained boolean, probably even if you factor in locking costs.
 
Couldn't you do a WaitOne on it for 1 millisecond?
This is a bad idea. First, it changes the state of the event if it's
signaled. You can set the event again, of course, but only if you take care
not to wait for it immediately again afterwards to "check" the status. In
the worst case you'd have to take over the responsibilities of the other
waiting threads.

Second, if the event is not signaled, waiting is likely to invoke a context
switch, which will probably take more than 1 millisecond, so this technique
doesn't scale. In fact, it's bizarrely more costly than checking a
self-maintained boolean, probably even if you factor in locking costs.
Click to expand...

So, it all depends on how often the OP wants to read it's current status.
Using WaitOne less frequently than, say, once a minute should pose no
problems. Using it more than a few times a second will be a problem. I
wonder what the OP had in mind?
 
Back
Top