prepareToPlay and processBlock thread-safety

So I’ve used the ThreadSanitizer (https://github.com/google/sanitizers) to find threading issues in my audio plugin, and noticed that it reports a data race for variables modified in prepareToPlay and read in processBlock.
This seems to be caused by prepareToPlay being called from a thread other than the audio thread.

So do I have to synchronize access to variables between prepareToPlay and processBlock, or do DAWs only call processBlock after prepareToPlay has returned? I assume yes, otherwise the ThreadSanitizer wouldn’t complain, I guess.

Also, is the thread that prepareToPlay is called on the Message Thread?

Unfortunately there are no guarantees here.

For “normal” use prepareToPlay is called on the message thread, then processBlock is called on the audio thread. If you are doing non-realtime rendering then both could be called on a different non-audio thread or the message thread.

Well behaved hosts won’t call both prepareToPlay and processBlock on different threads simultaneously, but there are a handful of badly behaved hosts out there. Usually when any of the JUCE team makes a statement like this we get a handful of people saying “I’ve developed plug-ins for X years and we’ve never seen a problem…” so if you’re not doing anything unusual then you’re unlikely to run into trouble. Edge cases do exist though:

1 Like

Thanks, so for now I’ll probably just look away from the race condition there and hope nothing breaks. I’m doing the same with the AudioProcessorValueTreeState thread-safety issues anyway ¯\_(ツ)_/¯