could std::intrinsics::atomic_max be exposed via an AtomicUsize::fetch_max method?

[spacejam]

As part of my recent work on supporting transactions in sled I've wanted to take advantage of the atomic_max intrinsic so that I can implement a lock-free concurrency control protocol more efficiently, without spinning on CAS in a loop. It would be wonderful if I could do this without relying on compiling C. Specifically, updating the read timestamp of an item read in an MVOCC transaction, where read items need to be marked as having been read "at least as high as" a transaction timestamp being executed by a particular thread.

Are there any blockers to adding this? I'm happy to write the code that exposes it if not.

[hanna-kruppe]

Note that if the hardware does not support atomic max, this is expanded to a CAS loop regardless. At least on the default x86_64 target that is the case (see playground).

[spacejam]

Ahh yeah, even with target-cpu=native on an i7. Dang, I let a wait-free fantasy develop without first verifying how the intrinsic works :P

    6f30:       48 83 f8 06             cmp    $0x6,%rax
    6f34:       b9 07 00 00 00          mov    $0x7,%ecx
    6f39:       48 0f 4f c8             cmovg  %rax,%rcx
    6f3d:       f0 48 0f b1 4c 24 08    lock cmpxchg %rcx,0x8(%rsp)
    6f44:       75 ea                   jne    6f30 <_ZN3amx4main17h5557c2e4c983c622E+0x20>

Anyway, I think introducing a max method to AtomicUsize would make this sort of operation less bug-prone and more accessible, as lots of people get (rightfully) scared away by the idea of writing CAS loops, or in more cases are probably not aware that this sort of thing can be done atomically. Still happy to introduce this if there is openness to it! I know I would use it :)

[Mark-Simulacrum]

This has since been added (#48655).