Re: [LAD] basic RT-thread model questions - Linux-audio-dev

7 Jun 2008

"Patrick Stinson":
...

 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? 
Yes, that is OK. But beware that a RT thread running with priority x 
waiting for a RT thread running with priority y, will in practice
only run with priority min(x,y). This is called priority inversion, 
there's probably a wikipedia article about it. In short: If all
threads run with the exact same priority, then it's OK.

...
  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 don't understand the question ("i have gathered are (...) a=>b 
message-passing (...) while (...  useless, since (...), given (...)
is negligable. (...)" ???), but it seems like others have, so
hopefully their answers are correct.