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

backlog: fix potential deadlock in a different way #1014

Merged
merged 1 commit into from
Jan 12, 2025

Conversation

brakhane
Copy link
Collaborator

The current implementation works insofar as that there is no deadlock, but unfortunately the entries data can become corrupted enough for the program to crash in the C++ stdlib.

For the new solution we use a shared_timed_mutex, allowing shared read access to entries, and only acquire a unique lock for writing. Since this can run into a deadlock if an error happens during rendering of the backlog itself, we only wait 33ms to acquire it (1 frame @ 30 fps).

If we can't get it by that time, we still write to debug output, but not into entries.

The shared_timed_mutex also allows us to wait for a read lock at the end of the program, so we now wait for 1s instead of giving up immediately.

This commit also fixes a missing synchronization when accessing history that was accidentially removed.

The current implementation works insofar as that there is no deadlock,
but unfortunately the `entries` data can become corrupted enough for
the program to crash in the C++ stdlib.

For the new solution we use a shared_timed_mutex, allowing shared read
access to `entries`, and only acquire a unique lock for writing. Since
this can run into a deadlock if an error happens during rendering of
the backlog itself, we only wait 33ms to acquire it (1 frame @ 30 fps).

If we can't get it by that time, we still write to debug output, but not
into `entries`.

The shared_timed_mutex also allows us to wait for a read lock at the
end of the program, so we now wait for 1s instead of giving up immediately.

This commit also fixes a missing synchronization when accessing `history`
that was accidentially removed.
@brakhane brakhane force-pushed the shared-lock-for-great-justice branch from c082838 to dca3568 Compare January 12, 2025 17:58
@turanszkij turanszkij merged commit 224ed34 into master Jan 12, 2025
3 checks passed
@turanszkij turanszkij deleted the shared-lock-for-great-justice branch January 12, 2025 18:27
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.

2 participants