Re: [LAD] basic RT-thread model questions

"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.

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Jun 7 20:15:02 2008