AudioProcessorGraph -- mutex is ok?

[tayholliday]

I was looking through the code for AudioProcessorGraph and I noticed there's locking of a mutex to update the renderingOps array (in AudioProcessorGraph::buildRenderingSequence()):

// swap over to the new rendering sequence..
const ScopedLock sl (getCallbackLock());

I'm trying to square that with the views of this article:

http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing

In practice, are mutexes not really a problem? Are OSes now smart enough to avoid priority inversion?

Also, I was wondering why renderingOps is an Array<void*>? Seems it should be Array<RenderingOp*>, with AudioGraph::RenderingOp forward declared as a private nested class in the header.

cheers

- Taylor

[jules]

In my experience, uncontended mutexes don't cause problems, and this one is only held for very short times and very infrequently by other threads, in circumstances where it'd be hard to justify doing things any other way.

Thanks for the heads-up about the Array<void*>, I didn't know that was still in there - yes, it would indeed be cleaner to use a private class name instead, which is what I normally do. I think this may be very old code!