IMHO atomics should only be for near intrinsic types/operations.

Anything larger is a programming paradigm for exclusivity or a
synchronization mechanisms that the user should write manually
themselves so they will know and understand that there is
potentially long lockout and be able to tune as appropriate.

No hand holding.

Chris++;

On Wed, May 8, 2024 at 2:19 PM Andrey Semashev via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> On 5/8/24 19:39, Thiago Macieira via Std-Discussion wrote:
> > On Tuesday 7 May 2024 22:19:57 GMT-7 Nate Eldredge via Std-Discussion
> wrote:
> >>
> >> However, many architectures
> >> have load-link/store-conditional instructions (e.g. ARM64 with
> LDRX/STRX)
> >> and could implement this more efficiently by executing f() in between
> the
> >> LL and SC. So in effect, fetch_update would expose the LL/SC
> >> functionality for use at the level of C++. It could also be implemented
> >> with transactional memory where available.
> >
> > That's interesting, but f needs to be extremely simple, otherwise that
> > machinery can't be used and the store-conditional will always fail. On
> some
> > architectures (and my LL/SC is very rusty), you cannot place function
> calls
> > between the two, so f must be always inlined.
>
> Another example might be no memory access instructions within the LL/SC
> pair. Even if they are formally allowed, page faults may get in the way.
> Which would make the whole concept extremely unreliable, as the compiler
> normally doesn't have those kind of restrictions and e.g. is free to
> generate loads from the function object state or bound variables. With
> optimizations disabled, the compiler will also generate loads and stores
> on the stack for every variable.
>
> I did consider implementing this concept for Boost.Atomic, but
> eventually decided that even if I did, the LL/SC instructions would not
> be the right backend for it. It would have to be either a CAS loop or
> something like x86 RTM. We know RTM is basically dead now, and I'm not
> sure there are equivalents on other popular architectures, so we're
> basically left with a CAS loop implementation only. This doesn't offer
> performance benefits, likely the opposite (because with a proper CAS
> loop you can optimize away an extra atomic load), so I dropped the idea.
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>