multithreading - Using a mutex in an audio callback -

when writing audio application, it's understood there unbounded operations should never used in audio driver callback. these operations typically include things allocating memory, reading or writing disk or network, locking mutex/critical section etc...

i'm re-writing audio engine of music app cantabile (http://www.cantabilesoftware.com) , entire engine lock free, except 1 area, on i'd appreciate opinion of others.

cantabile can leverage multiple processors/cores process audio. constructing tree of work items , waking pool of threads contribute getting job done. of threads in thread pool run @ highest priority possible (time critical + vista mmcss boost on windows) , don't else except audio processing (ie: they're not used other background utility tasks).

to implement use condition variable wake worker threads , single critical section serialize access work item tree. critical section has spin count , locked long enough worker pull next work item tree.

my rationale being ok is:

1. the spin counts should cover time needed other threads release lock.
2. even if spin count isn't enough there shouldn't issues priority inversion because threads running @ time critical priority.
3. none of worker threads perform other potentially unbounded operations (except possibly when processing poorly-written plugin there's not can that).

i've run many tests against , seems working well, matters have habit of tripping 1 when least expected.

am forgetting something?