[linux-audio-dev] Lock-free gtk/jack interaction

Paul Davis paul at linuxaudiosystems.com
Sun Mar 13 23:12:57 UTC 2005

>In Jackbeat (written in C), I have the gui running in one thread (the gtk main
>loop) and jack in its thread. Currently, when tracks get updated, the main loo
>sends a message to the jack thread, and then waits for an acknowledgement. I
>currently use syscalls (message queues) for these messages, but that's not my
>point (I'll turn that later into syscall-free fifos).
>Waiting for an ack from the jack thread has a consequence : it locks the gui f
>a brief moment, which seems to drive my spin buttons mad : when clicked they
>will sometimes step the value by 1, sometimes 2, etc...

don't wait in the GUI. what you need to do is to hook a notification
mechanism from the RT thread into the main event loop of the
GUI. having the RT thread write a byte to a FIFO or raise/lower a
semaphore are the two best generally available ways of having it
notify the GUI that something has happened that it needs to know about.

many programs use this mechanism.

>Message queues would still be used to let the jack thread update itself the
>"real" sequence. This is where would reside some latency : waiting for the jack
>thread to get in sync. But the gui would never lock.

forget the idea of "sync". your GUI has no way to update more than
about 60-80 times a second anyway (because of the monitor refresh
frequency. your  goal is to make sure that the GUI reflects the state
of the model/backend ASAP after the model/backend changes.


More information about the Linux-audio-dev mailing list