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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-08-08 12:15:46

On Fri, Aug 8, 2014 at 7:11 PM, Ion Gaztañaga <igaztanaga_at_[hidden]> wrote:
> El 08/08/2014 14:28, Lars Hagström escribió:
>
>> So I propose that atomic_write32 should be implemented using atomic_cas32.
>> Or indeed that Boost.Atomic should be used instead, which is more work,
>> obviously.
>
>
> [CC-ing Andrey]
>
> I'd like to use Boost.Atomic (assuming Boost.Atomic can be used in C++03
> mode). At least in all platforms where Boost.Atomic is available. The
> Boost.Interprocess atomics are broken and I don't have the skills to write
> correct code.
>
> I'd like to use a header-only solution but I see that's not currently
> possible with Boost.Atomic. I'd only use 32 bit atomic operations and only
> in platforms where those are lock-free, as it's the case now wirh
> Interprocess (we can't fallback to std::mutex-es and that's perfectly
> acceptable).
>
> Maybe it's a good task for Boost 1.57. Andrey, do you think porting to
> Boost.Atomic is a good idea? I don't know if Boost.Atomic supports all
> platforms Interprocess supports now (see
> www.boost.org/doc/libs/release/boost/interprocess/detail/atomic.hpp for
> details).

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:

- 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.
- 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.
- 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.