[linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write

Fons Adriaensen fons.adriaensen at skynet.be
Wed Jun 7 18:32:44 UTC 2006


On Wed, Jun 07, 2006 at 08:49:38AM -0400, Paul Davis wrote:

> nice to hear that they are faster. on the other hand, once again POSIX
> screws us all over by not integrating everything into a single blocking
> wait call. i've said it before, i'll say it again - this is one of the
> few things that the win32 API gets right - you can block in one call on
> almost *anything*. AFAICT, you cannot select/poll on a msg queue.

You can build such a thing on top of condition variables - that
is what they exists for - to let a thread wait one any condition
you may want, no matter how complicated. 

It's possible to do this in a very 'clean' way in C++.

First create 'service' classes for all the basic services you need:
message boxes, pipes, counting semaphores, whatever. These classes
should be handling the data only, not synchronisation. Derive them
all from an abstract base class that interfaces their state changes
to a second set of 'synchro' classes.  Each of these uses just *one*
condition variable, and that is the thing a thread waits for, by 
calling a 'synchro' object's wait().
Since _you_ design the condition in the 'synchro' objects it could
be anything you want, from simple readyness of any element in the
collection of 'service' objects you wait for (similar to poll/select)
up to things such as 'wake me up when all of mailboxes #1, #3 and #6
have some data and sema #5 has at least a count of ten'. You could
design a number of standard 'synchro' classes (as in libclthreads),
and/or create ad-hoc ones when you need them.

The problem then is all the system calls that use file descriptors,
as they don't provide the interface of the 'service' base class.
One solution is to delegate all use of such interfaces to 'helper
threads' that each wait on a single file, socket, or whatever.
You may want this delegation anyway for other reasons, e.g. disk
threads that read/write audio files in the background, or a thread
that receives and decodes OSC commands. 

-- 
FA

Follie! Follie! Delirio vano e' questo!



More information about the Linux-audio-dev mailing list