Boost logo

Boost :

Subject: Re: [boost] [Review] Boost.Atomic review starts today, October 17th 2011
From: Helge Bahmann (hcb_at_[hidden])
Date: 2011-10-17 11:22:57

On Monday 17 October 2011 16:25:02 Nick Edmonds wrote:
> On Oct 16, 2011, at 7:45 PM, Tim Blechmann wrote:
> > Hi all,
> >
> > The review of Helge Bahmann's Boost.Atomic library starts today, October
> > 17th 2011. It will end on October 26th.
> I've been anxiously awaiting the inclusion of this library in Boost for
> some time and would like to state up front that I wholeheartedly endorse
> it's acceptance. That being said there are a few issues I've run into
> using it over the last 6 months or so...
> I was actually pleasantly surprised to find that the PPC atomics worked
> with no modifications required on BlueGene/P, at least using the gcc 4.3.2
> build on my system.

I certainly hope they work well on any PPC/POWER platform, it's a target I
care a bit about :)

> Unfortunately because OSX does not support unnamed
> semaphores, Boost.Atomic doesn't run there.

could you explain a little bit what they are and where you are hitting these?
I can currenty only imagine the "fallback-via-locking" path, but that leaves
me puzzled as removing support for "native" atomics should make things worse
in this respect, rather than better, no?

> Using functions from libkern/OSAtomic.h would also be a valid approach
> rather than switching all PPC implementations to named semaphores.

the problem is that AFAICT they are fully synchronized and therefore rather
expensive especially on PPC

> Finally, with regard to making Boost.Atomic competitive with other portable
> atomics libraries (because on most of the systems I work on a C++11
> compatible compiler is a looooong way off), the only other one I've found
> to be remotely usable is OpenPA (
> It supports a variety of platforms/compilers and might be useful as far as
> finding out how to implement Boost.Atomic on those platforms/compilers, and
> the licensing is very permissive. Boost.Atomic's interface is far superior
> in my opinion though (thus the reason I didn't use OpenPA for my projects).

I am looking into extending platform support, the usualy problem is lack of a
test system -- I am a bit loathe to rely on just qemu for checking (there are
numerous kinds of problems it cannot show and that become visible on real

Best regards

Boost list run by bdawes at, gregod at, cpdaniel at, john at