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

11 Aug 2014

      I'd be happy to help out with testing any work on moving boost interprocess
to boost atomics. It would be good to get this cleaned up!

Anyway, for the Boost versions that are already out there I do need a
working patch that I can provide with my software. I've tried to have a
look at what Interprocess uses the atomic_write32 function for, to see if
release semantics is enough, but my atomic-fu is not strong enough for that.
So unless Ion tells me otherwise I am going to assume that sequential
consistency is needed and use the following implementation of
atomic_write32 (for gcc and x86/x86_64):

inline void atomic_write32(volatile boost::uint32_t *mem, boost::uint32_t
val)
{
  __asm__ __volatile__ ( "" ::: "memory" );
  __asm__ (
           "xchgl %0, %1"
           : "+r" (val), "+m" (*mem)
           );
  __asm__ __volatile__ ( "" ::: "memory" );
}

As is probably obvious, I am no assembly programmer, I just copied and
pasted relevant bits from Boost.Atomic, and this *appears* to work.

Thanks
Lars

On Fri, Aug 8, 2014 at 7:48 PM, Andrey Semashev 
wrote:
...
On Fri, Aug 8, 2014 at 9:21 PM, Ion Gaztañaga 
wrote:
...
El 08/08/2014 18:15, Andrey Semashev wrote:
...
- 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.
Correction, the macro value should be 2, not 1.
...
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.
Boost.Atomic is planned to have a more extended feature set than
std::atomic provides, so I can't use it.
...
...
- 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.
I used MSVC as an example. In theory, it is possible that some
platform only provides 64-bit atomics and Boost.Atomic has to emulate
32-bit ops. I don't know if such a platform really exists though.
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

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

Lars Hagström