I'm just asking these out of curiosity. I know you guys love these
kinds of questions :)
I know that the rule is to never block in a real time audio thread,
but what about blocking for resources shared between real-time
threads? In the case of a sequencing app that uses one thread per
audio/instrument track (as most do), is it OK to share a lock between
real time scheduled tracks? I ran into this question after
implementing a scripting engine for our commercial audio plugin using
python, which uses a global lock to serialize access to it's data
structures.
Also, I've gathered are that adding app-thread => RT-thread
message-passing to avoid using locks while modify the application's
basic shared data structures is useless, since the real-time thread
will have to wait for execution of that code one way or another, given
the overhead of acquiring the lock is negligable. This would mean that
you should just use locks and assume the user will cope with hearing
small overruns when adding/removing audio components. True? Not true?
I hope I worded these well enough. Cheers!