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

From: Kai Vehmanen <kvehmanen@email-addr-hidden>
Date: Thu Jul 21 2011 - 00:15:06 EEST

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... ;)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Jul 21 04:15:01 2011

This archive was generated by hypermail 2.1.8 : Thu Jul 21 2011 - 04:15:01 EEST