Is core.internal.atomic.atomicFetchAdd implementation really lock free?

[max haughton]

On Monday, 5 December 2022 at 01:37:02 UTC, claptrap wrote:
> On Sunday, 4 December 2022 at 12:39:44 UTC, max haughton wrote:
>> [...]
>
> I think you'll struggle to find any processor that defines 
> atomics in terms of memory ordering and not in terms of a 
> read/modify/write sequence that is executed atomically.
>
>
>> [...]
>
> I was working on lock free algorithms around 2008, there was an 
> intel pdf at the time specifying memory ordering. Tbh it 
> probably didn't need to be specified until multicore came about 
> since the default memory ordering on x86 single core meant you 
> you literally didn't need to worry about it.
>
> C++.. wild west? sounds about right :)
>
>
>> [...]
>
> Yes the only difference a lock prefix makes is it adds extra 
> ordering guarantees between cores. Basically the ordering 
> grantees you get on a single core, you get the same with locked 
> instructions between cores.

https://www.cl.cam.ac.uk/~pes20/weakmemory/x86tso-paper.tphols.pdf

Intel's initial efforts to specify the behaviour of the 
processors was not up to snuff at least in the eyes of academic 
researchers.