[LAD] basic RT-thread model questions

Kjetil S. Matheussen k.s.matheussen at notam02.no
Sat Jun 7 16:16:59 UTC 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.

More information about the Linux-audio-dev mailing list