[smart_ptr] Proposal to add new memory order constants
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...
On Thu, May 15, 2014 at 11:08 AM, Andrey Semashev
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...
Ping?
Andrey Semashev wrote:
Ping?
Uhh... No, I wasn't asleep at all, just resting... so you were saying...
On Thu, May 15, 2014 at 11:08 AM, Andrey Semashev
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. [...]
I have no objections. If you make a pull request I'll merge it.
BTW, maybe Boost.Atomic is a better place for memory_order.hpp?
It is. It was intended to go there. Problem was, when Boost.Atomic finally
landed, I didn't want to make shared_ptr depend on it.
It now however occurs to me that shared_ptr doesn't actually use the memory
order argument. So I can just make the functions take "int" and avoid the
#include. We can then move
On Tuesday 20 May 2014 17:51:01 Peter Dimov wrote:
Andrey Semashev wrote:
Ping?
Uhh... No, I wasn't asleep at all, just resting... so you were saying...
Oh, sorry, I didn't mean to spoil a vacation or anything. I should learn patience some day...
On Thu, May 15, 2014 at 11:08 AM, Andrey Semashev
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. [...]
I have no objections. If you make a pull request I'll merge it.
BTW, maybe Boost.Atomic is a better place for memory_order.hpp?
It is. It was intended to go there. Problem was, when Boost.Atomic finally landed, I didn't want to make shared_ptr depend on it.
It now however occurs to me that shared_ptr doesn't actually use the memory order argument. So I can just make the functions take "int" and avoid the #include. We can then move
to Boost.Atomic.
Maybe I should better create a pull request removing the header from Boost.SmartPtr? (Should I also remove it from tests?) I could then commit the modified header to Boost.Atomic myself.
Andrey Semashev wrote:
Maybe I should better create a pull request removing the header from Boost.SmartPtr? (Should I also remove it from tests?) I could then commit the modified header to Boost.Atomic myself.
The reverse, actually. You first add the header to Boost.Atomic (as is, without modifications). The link in boost/ will then point to one of the copies, but it doesn't matter which, as they are identical, so nothing will break. I will then remove it from SmartPtr. The link in boost/ will then be rerouted to the Boost.Atomic header and you can proceed with the changes. I will take care of the SmartPtr side. If you want to preserve history when adding the file to Boost.Atomic, the procedure is slightly more complicated: https://svn.boost.org/trac/boost/wiki/NewLibByRefactor
On Tuesday 20 May 2014 20:46:04 Peter Dimov wrote:
Andrey Semashev wrote:
Maybe I should better create a pull request removing the header from Boost.SmartPtr? (Should I also remove it from tests?) I could then commit the modified header to Boost.Atomic myself.
The reverse, actually. You first add the header to Boost.Atomic (as is, without modifications). The link in boost/ will then point to one of the copies, but it doesn't matter which, as they are identical, so nothing will break.
I will then remove it from SmartPtr. The link in boost/ will then be rerouted to the Boost.Atomic header and you can proceed with the changes. I will take care of the SmartPtr side.
Ok, sounds like a plan. I've added the unchanged file to Boost.Atomic in develop and master. Let me know when I can apply the changes.
If you want to preserve history when adding the file to Boost.Atomic, the procedure is slightly more complicated:
There seem to be no valuable history for that header, so I went the simpler way.
participants (2)
-
Andrey Semashev
-
Peter Dimov