Hello, Juce-y people. I’m bringing up a tiny worry I’ve had since I started using Juce.
Most of my “polling” threads are in fact event-driven, and what I’d really love to do is this:
[code]// In my worker thread:
// In another thread.
The trouble is that there’s a built-in race condition in this construct - because the notify might occur between checking the condition and the wait(-1).
Java gets around this problem by requiring you to lock the item (in this case, it would be the thread) before you wait for notification or notify. Behind the scenes, the JVM atomically removes the lock and puts you into the wait state, so there’s no possibility of a race condition.
It seems to be that this could be done with Juce by having, ugh, a single global “lock lock”. (I’m not proposing changing the existing wait, of course, but creating a new “lockedWait”.) While the idea of another global lock is somewhat repugnant, since it’s always the last lock to be taken it can’t ever be responsible for a deadlock.
So behind the scenes, when you get a “lockedWait”, you take the “lock lock”, unlock the locked object, call wait, and then release the “lock lock”. This prevents the race condition, but the one thing that can’t be done with current juce is releasing the lock AFTER the wait…
It’d be really nice to have this. As it is, I have all my threads spinning (usually wait(40)) even though I’m not sure if I’ve ever even seen this race condition once.