core.stdc.stdatomic

[claptrap]

On Friday, 17 November 2023 at 04:12:32 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 17/11/2023 11:50 AM, claptrap wrote:
>> LF algorithms rely on a sequence of operations being done in a 
>> specific order, and that order being coherent across 
>> cores/threads.
>
> Yes but there is a condition on this:
>
> 1. Each operation must be atomic, or:
> 2. Operate on an atomically synchronized memory

That's a given, I mean the whole point is any variable sharing 
across threads needs to be done atomically.


> But most importantly:
> 3. Must be predictable
>
> When you don't inline you get additional steps added that may 
> not hold this condition. Where it can be not atomic and not 
> operating on non-atomically synchronized memory.

CAS operates on a specific memory location and that address will 
be passed into the function, there's no way for the function to 
change this to break alignment and hence break the atomicity. In 
fact on x86 alignment doesn't matter anyway if you have a lock 
prefix. On Arm it does IIRC. But arm also has less strict memory 
ordering.

What instructions the compiler inserts around the CAS instruction 
are irrelevant, none of what they do can break the CAS. The only 
thing that the function has that can be used to barf things up is 
the memory location, everything else it has is thread local. So 
the only way the it can break the CAS is by reading or writing to 
the memory location in a non atomic manner. It literally has no 
instructions to do so unless the programmer tells it to. I mean 
if the compiler emits instructions to read or write to a pointer 
without the programmer instructing it to do so, your compiler is 
broken and you'll be getting segfaults everywhere anyway.