core.stdc.stdatomic

[Walter Bright]

On 11/14/2023 12:58 AM, Richard (Rikki) Andrew Cattermole wrote:
> On 14/11/2023 9:35 PM, Walter Bright wrote:
>> The fence instructions are supported by DMD's inline assembler, so they can be 
>> done, too, as simple functions.
>>
>> Why is this a write-off?
> 
>  From C11 spec for ``atomic_signal_fence``:
> 
> NOTE 2 Compiler optimizations and reorderings of loads and stores are inhibited 
> in the same way as with
> atomic_thread_fence, but the hardware fence instructions that 
> atomic_thread_fence would
> have inserted are not emitted.
> 
> In other words no instructions emitted, it does not map to an x86 instruction.

dmd does not reorder code around inline assembler instructions. So this is not a 
problem.


> I've said this before, dmd is a write off for lock-free concurrent data 
> structures. Having ANY extra functions in the call stack can throw off the 
> timing and end in segfaults. It MUST be inlined! This will be true of any use 
> case for atomics that is beyond that of reference counting.

Correct multithreaded code is about doing things in the correct sequence, it is 
not about timing. If synchronization code is dependent on instruction timing, it 
is inevitably going to fail because too many things affect timing.

Yes, dmd's code here will be significantly slower than an intrinsic, but I don't 
see how it would be incorrect.

As a path forward for DMD:

1. implement core.stdc.stdatomic in terms of core.atomic and/or core.internal.atomic

2. eventually add intrinsics to dmd to replace them