Re: [fluid-dev] Changes on CVS, needles and threads

[Tim Goetze]

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