From 7644276d24ec468417e8766e206659e9bf9c8f09 Mon Sep 17 00:00:00 2001 From: Christian Trott Date: Mon, 29 Apr 2024 17:48:31 -0600 Subject: [PATCH 1/2] Added changes for LEWG review --- atomic_accessor/atomic_accessor.md | 281 +++++++++++++++++++++++++++-- 1 file changed, 264 insertions(+), 17 deletions(-) diff --git a/atomic_accessor/atomic_accessor.md b/atomic_accessor/atomic_accessor.md index b7056382..c7a0c57f 100644 --- a/atomic_accessor/atomic_accessor.md +++ b/atomic_accessor/atomic_accessor.md @@ -1,6 +1,6 @@ --- title: "Atomic Refs Bound to Memory Orderings & Atomic Accessors" -document: P2689R2 +document: D2689R3 date: today audience: SG1 & LEWG author: @@ -12,6 +12,8 @@ author: email: - name: Daniel Sunderland email: + - name: Nic Morales + email: - name: Nevin Liber email: toc: true @@ -20,6 +22,16 @@ toc: true # Revision History +## P2689R3 (LEWG Feedback) + +- Split definition of _`atomic-ref-bound`_ into one for arithmetic and pointer, and one for other types + - needed because the typedef `difference_type` should only appear for arithmetic and pointer types +- Added discussion for making _`atomic-ref-bound`_ exposition only or not +- Added discussion arguing for not having converting constructors with respect to memory order +- Added missing `fetch_min` and `fetch_max` functions +- Use "west const" +- Added header synopsis changes + ## P2689R2 (SG1 Issaquah 2023 discussion) - Renamed `atomic-ref-bounded` to `atomic-ref-bound` @@ -278,6 +290,48 @@ a general exposition-only template `basic-atomic-accessor` which takes the `refe Assuming both papers are approved, SG1 voted that similar changes to `atomic_ref` in P2616R3 (Making std::atomic notification/wait operations usable in more situations) should also be applied to `atomic-ref-bound`. They are not yet in the wording of either paper, as we do not know what order LWG will apply them to the working draft. +## Exposition Only Or Not + +As mentioned above, during SG1 review we introduced explicitly named symbols instead of making `basic-atomic-accessor` and `atomic-ref-bound` public. + +The primary reason for not making the generic versions public is that the memory order is generally dictated by algorithmic considerations. + +The only generic thing one may want to decide is whether to use atomics at all (e.g. as the function of the execution policy). + +Consequently, we could not find a use-case where the generic types are useful. That said we also don't have a strong reason to not make them public - other than that it constrains implementers. + +## Memory Order Conversions + +A question was raised whether to make the various bounded `atomic_ref` and `atomic_accessor` variants constructible/convertible from each other. +We don't see many good reasons to enable that: + +- `atomic_ref` is meant to be almost used `in-place` for individual operations e.g. `atomic_ref(a[i])++` and not much of an interface type +- atomic accessors are something you are supposed to add in a fairly local scope too + - we don't expect folks to pass `mdspan` with atomic accessors around + +However we identified a possible reason not to permit it: + +Writing functions which take `atomic_ref_MEM_ORDER` imply ordering behavior: allowing conversions would make it very easy to violate that expectation. + +Consider the following: + +```c++ +void foo(atomic_ref_relaxed counter); + +void bar(int& counter) { + atomic_ref_relaxed atomic_counter(counter); + atomic_counter++; + ... + foo(atomic_counter); + ... + atomic_counter++; + atomic_thread_fence(memory_order::acq_rel); +} +``` + +We believe it would be potentially unexpected for `foo` to do any operations other than `relaxed` atomics on `counter`. +Likewise if `foo` were to take `atomic_ref_seq_cst` it would be surprising if it did `relaxed` atomic accesses. + # Open questions This proposal uses alias templates to exposition-only types for `atomic_ref_relaxed`, `atomic_accessor`, etc. @@ -286,6 +340,7 @@ For instance, if an implementer wished to derive from an `atomic-ref-bound`-like user friendly name mangling, which is something not normally covered by the Standard), would they be allowed to do so? We believe an alias template to an exposition-only type is not observable from the point of view of the Standard and such an implementation would be allowed, but we request clarification on this. +Potentially this is something we can leave to LWG review to suggest wording that would achieve that goal.