[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] Changes on CVS, needles and threads
From: |
Tim Goetze |
Subject: |
Re: [fluid-dev] Changes on CVS, needles and threads |
Date: |
Fri, 30 May 2003 17:21:23 +0200 (CEST) |
hi all,
back again.
[mutices, audio and other threads, shared data]
>Now the 'jack' documentation says that pthread_lock_mutex is not allowed
>in the process thread because it can delay for an indefinite time.
the jack docs are right, any realtime audio code path must be
free of calls to *_lock (even *_trylock can block with some c
libraries, and some semaphore implementations can also pose a
problem).
>Any good ideas how to do this right?
i resolved similar issues by queueing requests for modification of
critical data in a lock-free fifo (requires atomic ints, available on
every platform except some you find in gadgets like PDAs and
such iirc).
every time the audio thread is doing a cycle, it fetches and executes
requests from the fifo. this is fairly simple but gets a little more
complicated when the request requires the posting thread to receive a
result notification. not unmanageable though; pipe(2)s work well for
this purpose on linux.
you need one fifo for every thread that wants to post requests of
course, because the fifo's writer side cannot be made multi-thread
safe without some black assembler magic.
tim