20 Jul
2011
20 Jul
'11
11:25 p.m.
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... ;)