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
reply. Best,
Ion