5

Summary

If multiple threads are concurrently waiting on the same event handle, as in:

WaitForSingleObject(theHandle, INFINITE);

and the event is initialized to be manual-reset, as in:

// manual-reset and initial-state set to true
theHandle = CreateEvent(nullptr, true, true, nullptr);

then once the event is set, will all threads resume?

A little more detail

This example seems to indicate that they would all resume, without actually coming out and saying either way:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686915(v=vs.85).aspx

In my particular case, I have a small block of code where the event is manually reset, and in short order set again. i.e.:

ResetEvent(theHandle)

// Do some things that should not lock at all let alone deadlock

SetEvent(theHandle)

Then in practice I observe that some of the calls to wait for the event to be set will wait there indefinitely:

WaitForSingleObject(theHandle, INFINITE); // Hello, deadlock

The only things I can think of are that events don't work the way I think they should, hence the question, or that my "safe, lockless" code referred to above, isn't actually so safe and lockless.

Dan
  • 802
  • 6
  • 22

1 Answers1

2

Whan a manual reset event is set all waiting objects will resume. This is clearly stated on the MSDN page for SetEvent.

ScottMcP-MVP
  • 10,337
  • 2
  • 15
  • 15
  • 2
    'This is clearly stated on the MSDN page for SetEvent' yes, and it's somewhat misleading. If ResetEvent() is called immediately after the SetEvent, it is not guaranteed that all waiting threads will set running. Some threads may become ready and then get set to waiting again without actually running:( – Martin James Feb 22 '15 at 23:25
  • 1
    @MartinJames is correct. Calling ResetEvent() right after SetEvent() may have random results. Most likely the immediate call to ResetEvent() will cancel SetEvent() and waiting object will not resume. – Farshad Mohajeri Aug 18 '16 at 14:26