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

[claptrap]

On Sunday, 4 December 2022 at 12:39:44 UTC, max haughton wrote:
> On Sunday, 4 December 2022 at 10:15:48 UTC, claptrap wrote:
>> On Sunday, 4 December 2022 at 01:51:56 UTC, max haughton wrote:
>>> On Saturday, 3 December 2022 at 21:05:51 UTC, claptrap wrote:
>>
>
> X86 isn't the only processor

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.


> by atomics I am referring to the ones we use in programming 
> languages (note that I said modern). The ones in D are 
> basically inherited from C++11 (and LLVM), and we're drafted 
> because working with memory ordering prior to them was 
> wild-west.

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 :)


> X86 is also still ordered with or without a LOCK prefix. It's a 
> weaker kind of order but it's still defined

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.