I’d just like to add that all modern OSes use double lock checking for general purpose mutexes (for example JUCE’s CriticalSection), i.e. they first check if a lock is held with a cheap atomic memory operation. Only if it is contended do they need to call an expensive system call.
This means that a lock that is never contended is perfectly ok to use in realtime code. Obviously, a lock that is never contended is a bit useless, but we often need to use locks to guard against exceptional behaviour where a lock is only ever contended when the realtime guarantees are no longer valid anyway.
For example, if a lock in an audio callback guards against the audio device suddenly being removed (and it’s closed callback being called) then that’s perfectly fine. Obviously, it doesn’t matter anymore if the audio callback can fulfil it’s realtime guarantees when the audio device is no longer available. So it’s ok if the lock is contended in that situation.
Many of JUCE’s locks fall into this category. The remaining locks in realtime contexts are gradually being removed one-by-one and replaced with realtime safe paradigms.