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 (http://trac.mcs.anl.gov/projects/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 hardware) Best regards Helge