Subject: [boost] [smart_ptr] Proposal to add new memory order constants
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-05-15 03:08:46
I have a proposal to add new constants to the memory_order enum:
memory_order_hle = 16,
memory_order_hle_acquire = memory_order_hle | memory_order_acquire,
memory_order_hle_release = memory_order_hle | memory_order_release
These constants can be used to support Intel HLE (Hardware Lock
Elision)  in Boost.Atomic and then reused by Boost.Sync. The
meaning of these constants is Intel-specific (for now): the
memory_order_hle_acquire operation has memory_order_acquire ordering
and also starts a transaction; memory_order_hle_release operation has
memory_order_release ordering and also commits the transaction. On
other targets memory_order_hle flag is ignored and
memory_order_hle_acquire and memory_order_hle_release are equivalent
to memory_order_acquire and memory_order_release, respectively.
The support for these constants can be implemented in the following
- all x86 assembler-based backends.
- gcc __atomic* builtins support __ATOMIC_HLE_ACQUIRE and
__ATOMIC_HLE_RELEASE flags (at least, gcc 4.8 and Intel compiler
14.0.3 for Linux).
- MSVC x86_64 supports Interlocked intrinsics with _HLEAcquire and
_HLERelease suffixes. There are also _Store_HLERelease,
_Store64_HLERelease and _StorePointer_HLERelease. Unfortunately, these
only cover 32 and 64-bit types, for other types regular atomics will
be used (i.e. HLE won't be used). For 32-bit x86 asm blocks are also a
possibility; all types can have HLE support.
BTW, maybe Boost.Atomic is a better place for memory_order.hpp?
What do you think?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk