[linux-audio-dev] jack_callback <-> rest of the world

fons adriaensen fons.adriaensen at skynet.be
Sun Oct 30 07:36:41 EST 2005

On Sun, Oct 30, 2005 at 12:11:18PM +0100, Florian Schmidt wrote:

> Btw: i think when using a single mutex only for the condition variable
> (as opposed to the tutorial client which uses the same mutex for the
> signalling _and_ for synchronizing access to its data structure), the
> likeliness of contention is rather unprobable given that that the
> signaller aquires (again, of course via trylock) right before and
> releases the lock right after the pthread_cond_signal/broadcast. 
> Same for the singallee. As pthread_cond_wait releases the mutex while
> waiting and reaquires it before handing back control to the signallee
> the contention case becomes very unprobable when aquiring and releasing
> the lock right before and after the pthread_cond_wait.

This can still be so if the access to the shared data structure is
regulated by the same mutex that protects the condition variable,
provided that the operation on the shared data is very simple and fast.

It should never be necessary to hold the mutex while accessing the
samples, only while sending or receiving the information that the
samples are available.

In libclthreads, the operation performed while the mutex is held is
either incr/decr of a counter, or adding/removing an element at
the end/start of a linked list. Both operations are so trivial
that it would be silly to use a separate mutex for them.
The nice thing about condition variables is that they allow you
to re-use the mutex in this way, and in fact that's why they
exist at all.

Thinking a bit further, the conclusion is that the use of lock-free
data structures is warranted only iff the event passing mechanism
is lock-free as well, otherwise nothing is gained.

False wakeups are easy to avoid as well in this way. In libclthreads
the sender will only signal the single CV iff the change of state of
the ITC object (all the semas and mailboxes) would trigger some
action in the receiver, i.e. it checks what the receiver is waiting
for. In the other case only the state is updated.


More information about the linux-audio-dev mailing list