Boost logo

Boost :

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) [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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at