Boost logo

Boost :

Subject: Re: [boost] [smart_ptr] Proposal to add new memory order constants
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-05-20 02:00:42


On Thu, May 15, 2014 at 11:08 AM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
> 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/composerxe/compiler/cpp-win/GUID-A462FBC8-37F2-490F-A68B-2FFA8010DEBC.htm

Ping?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk