[LAD] a *simple* ring buffer, comments pls?

Kai Vehmanen kvehmanen at eca.cx
Wed Jul 20 21:15:06 UTC 2011


Hi,

thanks folks for the annual ringbuffer thread, it's always a pleasure to 
read (and you learn something new at every iteration). ;)

On Tue, 12 Jul 2011, Dan Muresan wrote:

> I wonder if
>
> {
> pthread_mutex_t dummy = PTHREAD_MUTEX_INITIALIZER;
> pthread_mutex_lock(&dummy);
> pthread_mutex_unlock(&dummy);
> }
>
> doesn't provide a portable full memory barrier. The dummy is different

This is exactly what I've been thinking about using in my code. It does 
have bit of a "i'm giving up" feel to it ;), but it would seem to be the 
only really easy, portable way to ensure a full barrier, even on exotic 
hardware. I'd love to use the new C++0x atomic+barrier ops, but I'm afraid 
that's still too bleeding edge as a build-dependency, and I'm not 
motivated enough to add (and test) a spagetti blob of autoconf magic to 
test for various available options.

> each time, so no contention -- but still inefficient since  this would
> be a 2-step full barrier. Nevertheless, it could be a portable
> fallback.

True, but I wonder if the performance hit is really big enough to warrant 
the complexity (in terms of additional testing and maintaining more 
optimal barrier implementations). Predictability, reliability (data 
coherency) and code readability might be worth more than the performance 
hit. But yeah, some actual numbers would be needed (and thus I'm still 
just contemplating using this approach).

PS My plan B is to wait and see for another 10 years (and many more
    long threads about this topic on this list), and then
    I can at least just start using C++0x already... ;)



More information about the Linux-audio-dev mailing list