On Mon, Sep 23, 2013 at 4:02 PM, Peter Dimov
Andrey Semashev wrote:
Also, intrin.h is an MSVC-specific header and I'm not sure it's portable across different versions of MinGW.
in this context probably includes the MingW64 header of that name.
I understand.
In the long term it might be worthwhile to use gcc atomic intrinsics to
implement BOOST_INTERLOCKED* macros.
BOOST_INTERLOCKED_* are not supposed to be implemented. If Boost.Thread uses them instead of the appropriate gcc atomics, this is a problem in Boost.Thread, not in interlocked.hpp.
The macros are supposed to provide low level atomic ops on Windows, aren't they? Wouldn't it be better to use gcc atomic intrinsics instead of WinAPI calls in case of MinGW? I'm not disputing now whether Boost.Thread should be based on Boost.Atomic, or whatever other abstraction layer.