prepareToPlay and processBlock thread-safety


#1

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?


#2

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:


#3

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 ¯\_(ツ)_/¯