Re: [LAD] basic RT-thread model questions

On Thu, 2008-06-05 at 10:34 -0800, Patrick Stinson wrote:
> 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?

Maybe. In theory it should be OK, I don't know enough scheduler magic to
be certain.

> 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?

Not true. The point with message-passing instead of locking a shared
structure is that the RT thread doesn't access the shared structure in
the first place - it has its own copy of the parameters it needs and can
keep on producing audio until it receives a message, at which point it
just changes its parameters in some RT-safe way (pointer swap etc) and
goes on producing audio. No glitch.

--ll

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev