Thread: SetEvent() and ResetEvent()?

I've never used events directly, so I'm not quite sure what the point of this code is? I see some code where they call SetEvent() immediately followed by ResetEvent().
As usual, there's no comments saying what it's supposed to be doing, so can anyone tell me why someone might want to signal & unsignal an event like that?

Code:

hEvent = OpenEvent( EVENT_ALL_ACCESS, TRUE, rt[i].DllResponderEvent );
BOOL serc = SetEvent( hEvent );

if ( serc == FALSE )
{
    // Log an error.
}

ResetEvent( hEvent );
CloseHandle( hEvent );

Originally Posted by Hunter2

Is this in some sample code? Could be that the Set and Reset lines actually have other code in between them. Alternatively, it could be a really funky way of checking that the Event was created properly (again, followed by some arbitrary lines of code before the Reset). Either way, this entire code section doesn't really do anything except create an event and destroy it.

Nope, it's actually in production software and it doesn't have any code in between except for some error logging if SetEvent() failed. There's a LOT of things like that in this code that make me scratch my head...

So basically, you're saying this code has no purpose?
I'm not gonna mess around with it one way or the other, but I'd like to at least understand the program flow before I start adding my changes...

Originally Posted by vart

It definitely has a purpose notifying some other thread that this part of the code was reached...

Event is opened by its name - so it is originally created in some other part of the code...
Here the event is signeled - so the wating function could exit...
and when reset back to non-signaled state - so it could be used again

But does the call to SetEvent() block until something else happens, or does it return immediately? If it doesn't block, then I don't see how other threads could get notified about the event unless a context switch just happened to occur between the SetEvent() and ResetEvent() calls.

The effect is to release ALL waiting threads, and then reset the event. If you want to release only 1 thread, then use PulseEvent.

Originally Posted by abachler

The effect is to release ALL waiting threads, and then reset the event. If you want to release only 1 thread, then use PulseEvent.

OK, but does SetEvent() guarantee that all threads will see the event in a signalled state before ResetEvent() sets it back to unsignalled? or do you need to call something like WaitForMultipleObjects() in between to make sure that all the threads heard the signal?

SetEvent will release all waiting threads.

I'm still a bit confused.
OK, let me put it this way: Lets say I'm running on single CPU machine, so only 1 thread can run at a time. I'm also running a million threads (just hypothetically of course) that are all waiting for an event.
Now, if I call:

Code:

SetEvent( hEvent );  // Nothing in between these lines.
ResetEvent( hEvent );

You're saying that SetEvent() doesn't block, so it will set hEvent to a signalled state, then immediately afterwards ResetEvent() will set hEvent back to an unsignalled event.

What I'm wondering is, how can all those other threads see that hEvent is signalled BEFORE it gets set back to unsignalled?

As cutey pie said, SetEvent() is a system call, the system releases all waiting threads before returning. This doesnt mean they all execute immediately though, they are just scheduled for execution.

Moved to Windows programming.

This is all assuming that the event was created as a manual reset event.

For manual reset events, here's some things you should keep in mind - say your thread(s) are looping on WaitForSingleObject(), then there is no telling how many loops will execute while the event is signaled (between the Set and Reset calls). Using the same loop construct, it's equally possible for any thread(s) to be in the middle of the loop (not inside a Wait function) during the entire duration the event is signaled - so that when it loops back around and calls a wait function, it blocks. In other words, those thread(s) never knew that the event was ever signaled.

If it's actually an auto reset event, then the code you posted basically means "release one thread that may be waiting on the event, and just incase there wasn't a thread waiting on the event, reset it".

gg