Should JUCE change the implementation of Thread and CriticalSection to use std::thread and std::mutex of C++11?

This is just a discussion here, not a feature request.
Since the C++11 standard library has full support for threads and mutex locks, shouldn’t JUCE change the implementation of thread-related classes to use this more standardized, platform-independent library?
Obviously, using the standard library to implement these things is much simpler and clearer than using a “one platform one implementation” approach.
So why doesn’t JUCE switch to this kind of implementation?

Yes, that’d be great in the long-run! We’ve adopted a few things already like atomics, and will convert a few more, but there are a few stumbling blocks where the juce classes provide functionality which the std ones don’t. Even some quite basic stuff like setting a thread priority isn’t possible with the standard library.

Also, we found that the performance of some things was a bit patchy (I think maybe mutexes were iffy on some platforms), so don’t want to change anything that’ll have a performance impact, though I’m sure that’ll get better in time.

4 Likes

For example Microsoft’s implementation of std::recursive_mutex has an unbelievable amount of abstraction/redirections that finally end up in calls to some binary library. I really don’t trust that over some simple class like Juce’s CriticalSection that just holds a Windows CRITICAL_SECTION and where you can simply see what is going on. While this is anecdotal and I didn’t extensively test it further, using std::recursive_mutex from the Microsoft C++ standard library I observed worse performance than with Juce’s CriticalSection.

2 Likes