>I saw you pointing to the problematic usage of mutex with >ringbuffers a couple of times now. In the most recent case >you mentioned a solution of yours without mutices (sorry, >I can't find the reference anymore ... probably was on LAD). > >To me it's not clear why protecting a ringbuffer with a mutex >is evil.
if something else holds the lock, pthread_mutex_lock() will block the calling thread. this means that at least two context switches plus a POSIX signal are involved before it gets running again. if you are running in a low latency environment with IPC involved in chaining a series of threads in different processes together (e.g. JACK, or even aserver for that matter), this is critical time. With 64 frames at 48kHz, you have 1300 usecs per interrupt. Dealing with the lock above will probably take at least 20usec (and quite possibly more, though it does scale in a somewhat linear fashion with processor speed). Thats 1.5% of the total time available. You have to add that to all the other "scaffolding" code that will be run at every device interrupt. Allow a few clients/threads to do that, and pretty soon, you're eating up significant chunks of time you'd rather spend running DSP code. blocking while in the code that is "handling" an audio device interrupt in a low latency environment is evil. it can't always be avoided, but when it can, its wise to do so. >I'm curious about how you manage to safely access a ringbuffer >in a multithreading environment without using a mutex lock. I browse the ardour.sf.net CVS repository. in ardour/libs/ardour/ardour/ringbuffer.h is a lock-free ringbuffer. it relies on single-reader/single-writer semantics, and also on the fact that if the reader or writer believes there is less data/space (respectively) available than there actually is, thats OK. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
