$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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 (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