how to read status of AutoResetEvent?

[buu]

so, I have a private object as system.threadin g.AutoResetEven t, 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....

[Jeroen Mostert]

buu wrote:

so, I have a private object as system.threadin g.AutoResetEven t, and I would
like to read it's current status.

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....

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 conditionMonito r = new object();

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

....

lock (conditionMonit or) {
conditionMet = true;
Monitor.Pulse(c onditionMonitor );
}

--
J.

[=?Utf-8?B?QU1lcmNlcg==?=]

so, I have a private object as system.threadin g.AutoResetEven t, and I would

like to read it's current status.

Couldn't you do a WaitOne on it for 1 millisecond?

[Jeroen Mostert]

AMercer wrote:

>so, I have a private object as system.threadin g.AutoResetEven t, and I would
like to read it's current status.

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 responsibilitie s 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.

--
J.

[=?Utf-8?B?QU1lcmNlcg==?=]

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 responsibilitie s 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.

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?