Re: [boost] [interprocess] atomic_write32 on GCC/x86/x68_64 lacks memory barrier

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