Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make WaitForMultipleEvents atomic when waitAll is true #20

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

mqudsi
Copy link
Member

@mqudsi mqudsi commented Jun 27, 2021

This patch significantly changes the behavior (and to an extent, the
performance) of pevents to more closely mimic the documented behavior of
WaitForMultipleObjects and WaitForMultipleObjectsEx.

As reported in #9, the previous behavior did not make any atomicity
guarantees when a call to WaitForMultipleEvents() was made with
waitAll = true, and WFME would attempt to serially obtain the events
in question, which could lead to a deadlock in case of circular locking
and auto-reset events.

The WFMO behavior documented on MSDN makes it clear that the Windows
implementation does not modify the signalled state of any of the manual
or auto reset events being awaited until the WFMO call is ready to
return, at which point either the one event in question or all the
events being awaited (dependent on waitAll) are atomically awaited.

Closes #9

Test contributed by @qwertymaster617, see [0] for associated issue.

[0]: #9
This patch significantly changes the behavior (and to an extent, the
performance) of pevents to more closely mimic the documented behavior of
`WaitForMultipleObjects` and `WaitForMultipleObjectsEx`.

As reported in #9, the previous behavior did not make any atomicity
guarantees when a call to `WaitForMultipleEvents()` was made with
`waitAll = true`, and WFME would attempt to serially obtain the events
in question, which could lead to a deadlock in case of circular locking
and auto-reset events.

The WFMO behavior documented on MSDN makes it clear that the Windows
implementation does not modify the signalled state of any of the manual
or auto reset events being awaited until the WFMO call is ready to
return, at which point either the one event in question or all the
events being awaited (dependent on `waitAll`) are atomically awaited.
If the initial number of events was zero and waitAll was set, this
assertion would fail incorrectly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

WFME( waitAll = true ) resets AutoReset Events before all Events are set
1 participant