Project: | ISO JTC1/SC22/WG21: Programming Language C++ |
---|---|

Number: | P0440r1 |

Date: | 2016-11-09 |

Reply-to: | hcedwar@sandia.gov |

Author: | H. Carter Edwards |

Contact: | hcedwar@sandia.gov |

Author: | Hans Boehm |

Contact: | hboehm@google.com |

Author: | Olivier Giroux |

Contact: | ogiroux@nvidia.com |

Author: | JF Bastien |

Contact: | jfbastien@apple.com |

Author: | James Reus |

Contact: | reus1@llnl.gov |

Audience: | Library Evolution |

URL: | https://github.com/kokkos/ISO-CPP-Papers/blob/master/P0440.rst |

- Apply Floating Point Atomic (P0020) to Atomic View (P0019).

- Editorial: add hyphenation to "floating point"
- 2016-11-09 Issaquah SG1 decision: move to LEWG targeting Concurrency TS V2

This paper proposes an extension to the
atomic operations library [atomics]
for atomic addition on an object
conforming to **atomic_view<T>** (P0019)
where T is a *floating-point* type (N5131 3.9.1p8).
This capability is critical for high performance
computing (HPC) applications.

Naming will conform to the to-be-determined naming convention selected for atomic view (P0019). The two currently proposed atomic view naming conventions are as follows.

namespace std {namespace experimental {template<> struct atomic_view<floating-point>;}}

OR

namespace std {namespace experimental {template<> struct atomic<floating-point& >;}}

namespace std {template<> struct atomic_view<floating-point>;}

template<> struct atomic_view<floating-point> {static constexpr size_t required_alignment =implementation-defined;static constexpr bool is_always_lock_free =implementation-defined;bool is_lock_free() const noexcept;void store(floating-point, memory_order = memory_order_seq_cst ) const noexcept;floating-pointload( memory_order = memory_order_seq_cst ) const noexcept;operatorfloating-point() const noexcept ;floating-pointexchange(floating-point, memory_order = memory_order_seq_cst ) const noexcept;bool compare_exchange_weak(floating-point& ,floating-point, memory_order , memory_order ) const noexcept;bool compare_exchange_strong(floating-point& ,floating-point, memory_order , memory_order ) const noexcept;bool compare_exchange_weak(floating-point& ,floating-point, memory_order = memory_order_seq_cst ) const noexcept;bool compare_exchange_strong(floating-point&,floating-point, memory_order = memory_order_seq_cst ) const noexcept;floating-pointfetch_add(floating-point, memory_order = memory_order_seq_cst) const noexcept;floating-pointfetch_sub(floating-point, memory_order = memory_order_seq_cst) const noexcept;constexpr atomic_view() noexcept ;atomic_view( atomic_view && ) noexcept ;atomic_view( const atomic_view & ) noexcept ;atomic_view & operator = ( atomic_view && ) noexcept ;atomic_view & operator = ( const atomic_view & ) noexcept ;floating-pointoperator=(floating-point) noexcept ;explicit atomic_view(floating-point& obj ) noexcept ;explicit constexpr operator bool () const noexcept;floating-pointoperator+=(floating-point) const ;floating-pointoperator-=(floating-point) const ;};

*regarding arithmetic operations*

*update remark as follows*

Remark:For signed integer types, arithmetic is defined to use two’s complement representation~~. There~~and thereare no undefined results.For floating-point types, if the result is not mathematically defined or not in the range of representable values for its type (5p4) the result is unspecified, but the operations otherwise have no undefined behavior. [Note: Atomic arithmetic operations onFor address types, the result may be an undefined address, but the operations otherwise have no undefined behavior.floating-pointshould conform tostd::numeric_limits<floating-point>traits associated with the floating-point type (18.3.2). The floating-point environment (26.4) for atomic arithmetic operations onfloating-pointmay be different than the calling thread's floating-point environment. - end note]