Subject: Re: [boost] [interprocess] atomic_write32 on GCC/x86/x68_64 lacks memory barrier
From: Ion GaztaÃ±aga (igaztanaga_at_[hidden])
Date: 2014-08-08 13:21:47
El 08/08/2014 18:15, Andrey Semashev wrote:
> I think Boost.Atomic should provide the common implementation of
> atomic ops for Boost libraries, so I agree that this would be a step
> in the right direction. However there are a few things to consider:
Ok. Glad we agree.
> - Looking at your current implementation, I think some platforms are
> not directly supported by Boost.Atomic. That is, I don't test for e.g.
> __IBMCPP__ or availability of Solaris functions in Boost.Atomic, so
> unless these platforms are supported by other backends (like gcc asm
> based, for example) these platforms will fall back to the lock-based
> backend. The list of the supported lock-free platforms can be inferred
> from the boost/atomic/detail/platform.hpp file (or the list of
> caps_*.hpp files there). Needless to say, I'm all for improving
> portability of Boost.Atomic, and I'll appreciate any help in
> supporting these platforms.
I think maintainers of those compilers and platforms should help us
supporting atomic operations. Interprocess can only require
BOOST_ATOMIC_INT32_LOCK_FREE to be 1 after including
boost/atomic/capabilities.hpp to test if needed atomics are available.
In this case, and if c++11 atomics are defined Boost.Interprocess could
try to use std atomics in the compiler supports it, but let compiler
experts write the assembler for those platforms.
> - The lock-based backend requires linking to a compiled library and is
> not capable of interprocess synchronization. You can use Boost.Atomic
> 1.56 and later in header-only manner, if you test for the library
> capabilities before including and using atomic<> (include
> boost/atomic/capabilities.hpp for that). But if there is no lock-free
> backend for a given platform there needs to be some alternative
> implementation in Boost.Interprocess. Or Boost.Interprocess should
> fail to compile on that platform.
I think it should fail to compile as it does now. Let's hope other
compiler maintainers provide atomic types. It would be nice if
Boost.Atomic used C++11 atomics in case they were available, that would
make Boost libraries easier to maintain, but for now Boost.Interprocess
can use C++11 if available.
> - The underlying storage type of atomic<> is not officially fixed for
> a given element type and may differ from one platform to another
> (including from one compiler to another on the same target hardware).
> For example, some versions of MSVC don't support 8 and 16-bit
> interlocked intrinsics and Boost.Atomic uses 32-bit atomic ops
> instead. Not sure how critical this is for Boost.Interprocess.
Not critical, all atomics are now only 32 bit. Thanks for your quick
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk