Critical Sections - okay in audio loop?


#1

Or are they too cpu intensive?


#2

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!


#3

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 …


#4

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.


#5

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” :slight_smile:
(I keep it in french, since I can’t translate it well enough)


#6

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.


#7

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 …


#8