Subject: Re: [linux-audio-dev] Multithreaded programming for a poll model?
From: Fons Adriaensen (fons.adriaensen_AT_skynet.be)
Date: Fri Jun 18 2004 - 01:08:21 EEST
On Thu, Jun 17, 2004 at 08:26:51PM +0100, Chris Cannam wrote:
> One way to do this is to use pthread conditions. Have a ring buffer
> between your decoder and RT threads, with the decoder sleeping for
> short periods of time between reads using pthread_cond_timedwait or
> similar. This causes the thread to sleep until a certain time has
> elapsed or a condition has been signalled. You can then signal from
> the RT thread using pthread_cond_signal to wake up the decoder thread
> each time something is read from the ring buffer.
In the threads classes I'm using in Aeolus and Jaaa, each thread can
wait on any combination of up 16 counting semaphores and up to 16
message queues, and a timeout. All of this is controlled by just one
condition variable and its associated mutex. No other ITC primitives
are used.
There are two methods to signal the semaphores:
destination->put_event (sema_id, increment)
and
destination->put_event_try (sema_id, increment)
Both will increment one of the semas in <destination> by <increment>,
possibly waking up the thread if the semaphore is in the set of events
that <destination> is waiting for.
The first one uses mutex_lock(), and could block in the improbable
but possible case that the destination thread is pre-empted when
it is just between the mutex_lock() and cv_wait() of its get_event()
method, and holding the mutex.
The second one uses mutex_try_lock(). It will never block, but it may
fail. This one should be used by a RT audio thread.
In Jaaa for example, there is a circular buffer between the ALSA or
JACK thread, and the thread that is doing the FFT analysis. Each time
at least N (= 4096 IIRC) frames are ready in the circular buffer, the
RT audio thread will try to increment one of the semaphores in the
FFT thread by one. In the unlikely case this fails, this is reflected
in the return value of put_event_try(), and the RT thread will just
remember this for the next time, when it will try to increment the
sema by one more. So the worst that could happen is that the FFT
thread's idea of the buffer state lags by N frames, and if N is a
small fraction of the buffer size this just doesn't do any harm at all.
To get its commands from e.g. the GUI thread, the RT audio thread uses
a non-blocking version of get_event(), also using mutex_try_lock(), after
having done its normal processing. So the audio thread will never be
blocked.
-- FA
This archive was generated by hypermail 2b28 : Fri Jun 18 2004 - 00:37:59 EEST