Boost logo

Boost :

Subject: Re: [boost] [Review] Boost.Atomic review starts today, October 17th 2011
From: Nick Edmonds (ngedmond_at_[hidden])
Date: 2011-10-17 10:25:02

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. Unfortunately because OSX does not support unnamed semaphores, Boost.Atomic doesn't run there. I would love if the switch to named semaphores was quick and painless, but if that isn't the case it would be nice to have a compile-time warning in addition to the run-time error that occurs. The run-time error is actually relatively informative, but has still resulted in me getting a few emails from confused users. Something like:

#elif defined(__GNUC__) && (defined(__APPLE__)
  // Warning: Unnamed semaphores not supported on Mac OS X

would be helpful. A compile error would also be acceptable, but it's nice to be able to check my builds on my OSX desktop before moving code over to one of the clusters even if they won't run so I'd probably remove the error in my local copy.

Using functions from libkern/OSAtomic.h would also be a valid approach rather than switching all PPC implementations to named semaphores. Support for ICC intrinsic atomics would also be most welcome, but by no means necessary.

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).

With regards to interface and design I have no complaints whatsoever, I'd just like for Boost.Atomic to work on more platforms so that I can give up alternate implementations entirely!

Nick Edmonds

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