Following on from the extremely interesting discussion on data races here: AudioParameter thread safety
I decided to start paying more attention to these kinds of things in our app. I’ve been aware of Thread Sanitiser for a couple of years but it appeared in Xcode 8 so you can use it as part of your everyday toolchain.
One thing I immediately found was a ton of issues within the JUCE library. Now, a lot of these may be “benign”, and not actually have any serious consequences but it does make it virtually impossible to find real data races in your own code. It’s like having a project with several thousand warnings after building and trying to find the ones that will actually cause an issue.
Have the JUCE team thought about using TSan at all and possibly addressing some of these issues? It would be nice to be able to say JUCE is ASan, TSan and static analyser issue free and mean we can use these tools ourselves to avoid problems.
I imagine the JUCE 5 fade to C++11 would be a good time to do this.
A good place to start is just run the JUCE demo app and start selecting the pages. You’ll see various things appear in the “Runtime Issues” side pane.
I’m aware there is the argument that avoiding all “benign” data races would complicate some code but I think it’s more important for a library (especially the core code, perhaps not the examples) to be 100% thread safe or at least provide notes when something is left deliberately thread unsafe.
Just a thought…