Fix thread safety/data races between game and sound effect mixer threads #10147
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation / Problem
There were data races on the MixerChannel active states. Marking a channel active form the game thread side was not properly synchronised with checking if it was active from the mixer thread, and vice versa when the mixer thread marked it no longer active.
Less importantly, the effect volume setting was not updated in a technically thread safe manner.
ThreadSanitizer output
The reporting of performance measurements via
PerformanceMeasurer framerate(PFE_SOUND)
was also not thread safe.ThreadSanitizer output (performance measurement)
Description
Use a std::atomic for mixer channel active states, with proper ordering semantic so that the MixerChannel access is thread-safe.
Use a std::atomic for the effect volume (in a similar way to how music volume is handled).
Store PFE_SOUND measurements into a mutex-protected buffer which is then drained by the main thread.
Limitations
N/A
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.