Or are they too cpu intensive?
Fine in an audio loop - they’re very quick and often essential… but make damn sure that no other thread will block the audio thread for any significant amount of time!
In fact, for real-time capabilities (such as inside VST process callbaks), a thread should not have to wait on any external event. Thus, only TryEnterCriticalSection() is allowed in such a context …
oh, I’m not sure I totally agree with that - if your audio thread needs something from another thread and the other thread has the lock, then if you give up immediately, it’ll definitely glitch. But if you let it wait a moment for the thread to do its thing, then you still have a chance of playing the block in time.
I often lock audio threads just to do things like pass a few variables between it and a background thread. You just need to keep the locking to an absolute minimum.
Well, my arguments are pure theory. The problem is that the time your thread will be waiting on an external critical section can not be precisely evaluated. Which is unacceptable from a theorical point of view but works well in most cases.
“La différence entre la théorie et la pratique est qu’en théorie il n’y a pas de différence entre la théorie et la pratique”
(I keep it in french, since I can’t translate it well enough)
true, but as long as you know exactly what can happen in the external section, you can be pretty confident, especially since a good OS will temporarily boost the priority of a thread if it’s got a real-time thread waiting for it to complete.
I meant real-time capabilities in the sense of execution time predictability, not in the sense of access priority to computation resources.
Sorry, if it wasn’t clear …