win32 : Get the state of an event object.

Question

I'm creating 3 events with the following function:

HANDLE WINAPI CreateEvent(...);

I'm waiting on all (bWaitAll is set to TRUE) event objects or a timeout with:

DWORD WINAPI WaitForMultipleObjects(...);

The return value is:

WAIT_TIMEOUT

Is there an easy way to check each event to find the one(s) that was(where) not set?

As an example :

HANDLE evt1 = ....
HANDLE evt2 = ....
HANDLE evt3 = ....

HANDLE evts[3] = ....

DWORD ret = ::WaitForMultipleObjects(3, evts, TRUE, 10000);

After 10 sec :

• 'ret' is WAIT_TIMEOUT.
• evt1 is set
• evt2 is NOT set
• evt3 is set

The return value tells me "The time-out interval elapsed and the conditions specified by the bWaitAll parameter are not satisfied.", but not which one were signaled and which one were not.

Thanks,

Answer 1

Yes, after WaitForMultipleObjects() returned call WaitForSingleObject() for each event specifying zero timeout.

It will return WAIT_TIMEOUT for events that are not signalled and WAIT_OBJECT_0 for signalled events. Don't forget to check for WAIT_FAILED.

Surely each event state might have been changed compared to the states they had at the moment WaitFormultipleObjects() returned.

Answer 2

If your call returns WAIT_TIMEOUT it means that NONE of the objects you waited for was signalled..

Answer 3

OK. Total rewrite after having the question explained to me better in the comments.

So if I'm understanding this right now, you are calling WaitForMultipleObjects with bWaitAll set to true, and when you get WAIT_TIMEOUT back from it, want to figure out which objects are holding up the works.

In that case, I'm with sharptooth, sort of. You can call WaitForSingleObject with a 0 timeout for each object. The problem with doing this is that it has side-effects for some objects. For example, if you do this on a mutex and it succeeds, you not only know it wasn't the culprit, but you now own the mutex. If that isn't what you want, you'll have to know to immediately release it.

Any apporach you take is going to be subject to race conditions. Since you are outside of the "atomic" wait call, you could go through the process and discover that now they are all ready. You could get back a set of ready/unready that isn't what you actually had inside the wait call.

Ick.