Home/ Questions/Q 1015885
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T10:28:01+00:00

It is best to describe my question in an example: We create a Windows

  • 0

It is best to describe my question in an example:

  1. We create a Windows Event handle by CreateEvent, with manualReset as FALSE.
  2. We create 4 threads. Ensure that they all start running and waiting on the above event by WaitForSingleObject.

  3. In the main thread, in a for loop, we signal this event 4 times, by SetEvent. such as:

    for (int i = 0; i < 4; ++i) ::SetEvent(event);

My question is, can we say that all these 4 threads will certainly be waken up from waiting on this event?

According to my understanding of Windows Event, the answer is YES. Because when the event is set, there is always a thread waiting for it.

However, I read on MSDN that “Setting an event that is already set has no effect“. Since the waiting threads probably do not get a chance to run while main thread setting event in the loop. Can they still be notified and reset the event to nonsignaled? If the event is not reset, the following SetEvent in the loop is obviously useless.

Or the OS kernel knows which thread should be notified when an event is set, and reset this event immediately if there is a waiting thread. So the waiting thread does not need to be schedule to reset the event to nonsignaled?

Any clarification or references are welcome. Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Because when the event is set, there is always a thread waiting for it.

    No, you don’t know that. A thread may indefinitely suspended for some reason just before the NtWaitForSingleObject system call.

    Since the waiting threads probably do not get a chance to run while main thread setting event in the loop.

    If a thread is waiting for an object, it doesn’t run at all – that’s the whole point of being able to block on a synchronization object.

    Can they still be notified and reset the event to nonsignaled? If the event is not reset, the following SetEvent in the loop is obviously useless.

    The thread that sets the event is the one that resets the signal state back to 0, not the thread that gets woken up. Of course, if there’s no thread waiting the signal state won’t be reset.

    Or the OS kernel knows which thread should be notified when an event is set, and reset this event immediately if there is a waiting thread.

    Yes, the kernel does know. Every dispatcher object has a wait list, and when a thread waits on an object it pushes a wait block onto that list.

    • 0