On Fri, Aug 8, 2014 at 9:21 PM, Ion Gaztañaga
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.