[LAD] basic RT-thread model questions

[Patrick Stinson]

On Thu, Jun 5, 2008 at 10:47 AM, Lars Luthman <lars.luthman at gmail.com> wrote:
> 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.

We haven't seen any drop in performance at all and are going to
release, so I suppose that's "good enough for us". The cool thing is
that python has been **AWESOME** (that's four starts, kids) in the
real time threads. The python lib is only accessed from our audio
kernel(s), with script source set with using downstream message
passing, and exceptions and redirected stdout using upstream message
passing.

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

That makes sense. We are using a pointer swap in the message queue
using platform-specific atomic compare and swap functions. I wasn't
the one that implemented it, but the concept seems to make sense now.

>
> --ll
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>