Skip to content

fix handle spurious wakeup wrongly returning Flush too early #340

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

Merged
merged 14 commits into from
Jul 22, 2025

Conversation

hendrikmuhs
Copy link
Contributor

@hendrikmuhs hendrikmuhs commented Jul 18, 2025

add an atomic bool to check if flush has actually happened and condition variable did not spuriously wakeup.

fixes #339

2 important changes that fix this behavior hard-to-debug race condition:

  • the condition can wake up despite not being notified, that's why we need an extra atomic bool
  • the mutex should still be locked when calling notify, the problem is lifetime:
    • if the mutex is unlocked, the condition variable might get destructed after the destruction of the mutex, by moving it in scope, the lambda is fully destructed before the consumer side kicks in. The consumer holds the mutex that's why the mutex is in scope when the condition variable goes out of scope
    • error: std::__1::system_error: mutex lock failed: Invalid argument

Note:

  • I've run many loops here: c1af918 to test this, reverted for this PR
  • I think this race condition happened only for clang / on mac, I haven't checked if clang on Linux would show the same thing, likely yes

@hendrikmuhs hendrikmuhs merged commit e082ee0 into KeyviDev:master Jul 22, 2025
17 checks passed
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.

Flush issues on Mac due to spurious unblock of condition variable
2 participants