Re: [linux-audio-dev] Locks or no locks?

The skinny:

- Never make a blocking call in your synth thread; there are ways around it.
Using a thread lock is a blocking call.
- Use atomic operations where possible and for as long as possible to avoid
complicated messaging code.
- Have the synth thread operate on built-in types (int, float, bool)), which
can safely be set by any thread without worrying about locking.
- Use a timer in the gui thread to make a callback to update widgets based
on atomic values set by the synth thread. 20 ms is fine. Use a boolean to
indicate that a resource has changed and should be read.

This will get you through most problems. On the other hand, automating
controls (as is done in most plugin architectures like vst) is something
that needs to be event based from the synth thread to the ui thread, and you
will need to figure out a non-blocking message queue for that. For that I
leave the solution open to others in this list.

On 1/11/07, nick thomas <jesuswaffle@email-addr-hidden> wrote:
>
> I apologize if this has been discussed previously on the list; Google
> didn't seem to be turning anything up from the list archives.
>
> I'm writing my first DSP program for JACK. My problem is this: I've
> got a high-priority audio synthesis thread, and a low-priority user
> interface thread, and they need to communicate: the UI thread needs to
> tell the synthesis thread to respond to the user twisting knobs and
> moving sliders in the interface, and the the synthesis thread needs to
> tell the UI thread what it's doing, so that the UI thread can update
> its monitoring widgets. I'm sure that this is an extremely common
> situation for JACK programs, and I was wondering how to handle it.
>
> I know of two possible approaches: using locks and shared memory, or
> using FIFOs and no shared memory. Vanilla pthreads provides direct
> support for the former approach, and JACK's ringbuffer interface seems
> to provide the necessary primitives to implement the latter approach.
>
> A lock-based system would probably be substantially simpler to
> implement than a lock-free one; however, I can imagine some possible
> priority inversion issues with a lock-based system. I don't know if
> that is ever a problem in practice, with real-time scheduling enabled.
>
> Anyway, there's my question: which approach (lock-based or lock-free)
> is generally favored for JACK programs? Thanks for helping a newbie
> out!
>

-- 
Patrick Kidd Stinson
http://www.patrickkidd.com/
http://pkaudio.sourceforge.net/
http://pksampler.sourceforge.net/