Continue the discussion of early bail offline (idempotent operations being said to be non-synchronizing while allowing strengthening as well).

Want an atomic min/max operation.
Yay 9 Nay 1

We want this operation (with the semantics we determine are right) to be called fetch_min/max.
No objections.

P0493R2 Atomic maximum/minimum (Al Grant, Bronek Kozicki)

The paper was seen by LEWG ML review. summary:

• A request for benchmarks demonstrating the facility is better then the CAS + loop
  Authors: The performance benefit is that a non-CAS implementation would instead rely on an existing CPU-level implementation which, as the paper explains, is already available on many platforms (Editor's note: this is standardization of existing practice).

• A request for a "Tony table" of code with and without the proposed functions
  Authors: Example of CAS exists in N2396. Example of 'atomic_fetch_max':

T atomic_fetch_max(T value)
{
    unsigned long read = this->load();
    while (value > read) {
      if (this->compare_exchange_weak(read, value))
        return read;
    }
    return read;
}

• Regarding the write barrier macro - Is it possible that code built for an architecture that doesn’t need the barrier could run on an architecture that does, or vice versa? Point is to avoid making things compile-time constants when they might more correctly be decided at run time.
  Authors: This is a very good question. One platform made its behaviour in the past subject to environment flags.
  I hope that if such a macro was provided, it wouldn't need to be used often and in cases when it would make a difference, an alternative algorithm could be found.
  Perhaps by NOT defining such a macro, we will encourage that all algorithms should be written this way and end up with better lockfree designs.

• Strong support in the proposal: 

  • Functionality proposed on this papier, will eliminate 99% of the CAS loop usages in the code I have written, and by doing so improve its usability.
  • Many implementations already provide intrinsics for these operations, and they are both widely used and work well.

I didn't recognize objections to the proposal.
I recommend that the authors will add the examples requested, and that we'll move fixed revision directly to electronic polls.

A Library Evolution motion was made to advance this paper directly to electronic polling. The motion failed; additional Library Evolution and Concurrency (SG1) discussion is needed.

Why not also for floating point atomics? I mean min/max are useful there too, and this isn't functionally really different from atomic_add/sub which we did provide in C++20.

We also may need to extend atomic_ref with the corresponding thing to keep atomic and atomic_ref in sync?

This issue tracker is intended exclusively for paper management and organization. Any technical discussion about a paper's content should go to the appropriate committee reflector or be raised at a face-to-face meeting (if any).

@crtrott - you are most welcome to send your input on the mail thread "LEWG(I) Weekly review - P0493R2: Atomic maximum/minimum"

LWG reviewed and approved in Issaquah

https://wiki.edg.com/bin/view/Wg21issaquah2023/P0493R4-20230209

poll: adopt P0493R4 for C++26?

P0493R4 Atomic maximum/minimum (Al Grant, Al Grant, Bronek Kozicki, Tim Northover)

This was pulled from the polls in Varna, and there are some questions regarding min/max for floating-point types that need to be resolved (either by a new revision of this paper, or by another paper).

@jwakely there is a paper regarding min/max for floating-point types: P3008 (#1672) . SG1 saw it in Kona '23, SG6 will see it next, and then it will go to LEWG.

Needs a revision to apply feedback from this thread: https://lists.isocpp.org/lib-ext/2024/01/26442.php

P0493R5 Atomic maximum/minimum (Al Grant, Al Grant, Bronek Kozicki, Tim Northover)

P0493R5 dropped the floating-point change (will be resolved separately by P3008), sending P0493R5 back to LWG for C++26.