[LAD] basic RT-thread model questions

[Lars Luthman]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080605/47d6bceb/attachment.pgp>