Skip to content

Race conditions in ChannelData #21

Description

@Rincewind34

Hi again about multi threading

ChannelData also raises a bit suspicion. The rmsHistory should really be a vector of atomics, getAvgRMS (from UI thread) clashes with pushRMS (from AudioThread). You did it right with the rmsSum field.

Then there is also a race condition inside pushNextRMS because it might be called by the UI thread by decayIfNeeded. I would highly suggest removing that from LevelMeterSource and by that use a const reference to the LevelMeterSource in LevelMeter. You could do the time check inside the LevelMeter class and just "render zeros" no matter whats inside the LevelMeterSource.
If thats not possible, I would make rmsPtr atomic too and use "fetch_add" in pushNextRMS to read and increment the ptr in one atomic action. You'd calculate the module operation every time so the ptr just increases until the max value of size_t and then overflow to start over at zero (perfectly acceptable behaviour).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions