Boost logo

Boost :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-10-18 12:26:22

Markus Schöpflin escribió:
> Hello,
> attached patch introduces support for the atomic ops needed by
> interprocess on Tru64/CXX/Alpha. It currently misses support for atomic
> add and sub, but those are not used right now.

Applied in SVN. If I've introduced any error (I've applied the patch by
hand), please feel free to commit a fix.

> There are a few issues I would like to raise regarding the atomic
> operations:
> 1) Currently it is not specified whether an atomic operation implies a
> memory barrier or not. This should be explicitly stated.

They should imply a barrier. Since this was an internal header, I
haven't documented anything. Now that people is contributing, at least,
I should add a comment to the header.

> 2) atomic_sub32 does not return the old value, but atomic_add32 does.
> This seems inconsistent to me.

I agree. Nevertheless, I think atomic_add32 is enough since atomic_sub32
can be implemented as with atomic_add32(boost::uint32(-val)). I'm
planning on removing some unused operations, to maybe is time to remove

> 3) Has the use of the low level atomic ops API as proposed in WG21/N2047
> (see
> been considered. If yes, why has it been rejected? If no, would it makes
> sense to use this API?

If you are talking about using N2047 in Interprocess, I always thought
that boost/interprocess/detail/atomic.hpp was a temporary solution until
an atomic operations library was developed. I just needed some basic
operations and a full barriers were good enough for me. Developing an
atomic operations library is rocket science for me.

> 4) Is there a need for an atomic ops boost library? I seem to remember
> that other libraries need atomic ops as well.

Definitely yes. I'm still surprised that there are no atomic operations
on Boost apart from shared_ptr internals. I think we have people with
deep knowledge on atomic operations, so let's put some pressure on the
mailing list...

> Regards,
> Markus



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