LL/SC is also hard to abstract over. I don't know how it is for ARM, but on
RISC-V there are very strong restrictions about what you can actually do
between the LL and SC (or the SC will uncontionally fail) - one of which is
no branches, so the abstraction basically requires inlining to happen (or
otherwise, is allowed to reliably fail for no reason - not fail spuriously,
because spurious implies that the failure isn't reliable).

On Mon, 22 Jul 2024 at 07:28, Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Mon, 22 Jul 2024 at 08:00, Jens Maurer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>>
>> On 22/07/2024 00.23, Joseph Schuchart via Std-Proposals wrote:
>> > I'm not sure that this API could be implemented everywhere
>>
>> And here's the problem: I don't know how you can provide ABA
>> avoidance if all your hardware has is atomic compare-and-swap.
>>
>> So, this doesn't really help write portable programs.
>>
>> We have rather few features in C++ that aren't available on all
>> implementations, so the introduction of such a non-portable
>> feature needs additional rationale.
>>
>
> And for better or for worse, "not supported on x86" is likely to need a
> lot more rationale than "not supported on AVR" (for example).
>
>
>
>>
>> (There are plenty of hardware features that aren't available
>> everywhere, yet we strive to make C++ interfaces on them that
>> can be implemented everywhere, e.g. std::simd.)
>>
>> Jens
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>