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

[Iain Buclaw]

On Wednesday, 30 November 2022 at 00:35:55 UTC, claptrap wrote:
> On Wednesday, 30 November 2022 at 00:16:00 UTC, rikki 
> cattermole wrote:
>> On 30/11/2022 1:12 PM, H. S. Teoh wrote:
>>> Hmm, that's weird that the docs would say that.  I've always 
>>> been under
>>> the impression that core.atomic ops use locks to achieve 
>>> atomicity.
>>
>> No its correct.
>>
>> As long as the hardware supports atomic operations, it'll use 
>> those instructions. It does have a fallback to use a mutex if 
>> need be though, which might be where you got that idea from.
>
> It really shouldn't do that IMO. People expect atomic ops to be 
> lock-free, it should be compile error if it cant be so.

C++'s 
[std::atomic](https://github.com/gcc-mirror/gcc/blob/a1b5cdf381d6b02f5048d886a8377d0042bda3af/libstdc%2B%2B-v3/config/cpu/generic/atomicity_mutex/atomicity.h#L46) has followed this precedent too of using a mutex *if all else fails*.

Really, you'd have to be pretty explicit in forcing GDC built-in 
atomics to be disabled at configure-time - there's an atomic 
library [right there in GCC's 
tree](https://github.com/gcc-mirror/gcc/tree/master/libatomic) if 
a given target does not have native support.