While looking into MidiKeyboardState, I realized it has a lock that can be locked by both the GUI (when the keyboard inserts new notes in it) and the processBlock() when processing those messages (processNextMidiBuffer(), at least I guess the intention was that to be called from there with the incoming MIDI buffer). I was surprised, why it’s not using a non-blocking method, but maybe I shouldn’t be? Maybe somebody with deeper understanding how a processor is scheduling threads can enlighten me, but my understanding is that if we have a lock in a thread (like MessagManager here) even if that lock is unlocked after an instruction, that doesn’t mean the other thread will continue to run, it definitely need to wait to get its timeslice back and that can be quite bit of a time. So I would think, lock something for a short time is better than long time, but still can cause glitches.
Or shouldn’t we worry about short locks in 2020 if it’s rare? What counts short enough? In the past I totally rejected locks in the processing thread, but I have a feeling there are a classes we use from the JUCE library that introduce locks and memory allocations (even posting an ASync msg request will use an Array that can reallocate its memory if needed, or your logger will create a string on the fly… so it’s maybe more common than locks).