Hi, 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) [1] 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 Boost.Atomic backends: - 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? [1] https://software.intel.com/sites/products/documentation/doclib/stdxe/2013/co...