There have been multiple requests to add this support. It can all be done with a library implemented with some inline assembler.

Anyone want the glory of implementing this?

For the most part it looks like everything is in core.atomic already.

The only thing that looks like it isn't is ``atomic_signal_fence`` and that has to be an intrinsic as it is specifically for a backend instruction.

But reminder: only dmd is missing the intrinsics necessary to do atomics correctly without memory errors. Dmd is a right off if you are doing anything more than just reference counting with it.

On 11/13/2023 8:56 PM, Richard (Rikki) Andrew Cattermole wrote:
> For the most part it looks like everything is in core.atomic already.
> 
> The only thing that looks like it isn't is ``atomic_signal_fence`` and that has to be an intrinsic as it is specifically for a backend instruction.
> 
> But reminder: only dmd is missing the intrinsics necessary to do atomics correctly without memory errors. Dmd is a right off if you are doing anything more than just reference counting with it.

Aside from fence, they can all be done with simple functions. So why not?

On 11/14/2023 12:24 AM, Walter Bright wrote:
>> Dmd is a right off if you are doing anything more than just reference counting with it.
> 
> Aside from fence, they can all be done with simple functions. So why not?

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?

Question: Why do people want another wrapper around some inline assembly that already exists in core.atomic?

Answer: they don't. This does not allow people to implement any new ideas.

We don't need another wrapper around the same inline assembly that has the exact same tradeoffs with inlinability (it can't be inlined) and without the ability to succinctly communicate with the backend to ensure codegen looks the way it needs to.

You want to port code from C? Use core.atomic, but wait it has different behaviors? Well yeah... its not designed around the intrinsics that stdatomic.h is that give it any useful meaning.

See: ``kill_dependency``, ``atomic_init`` and ``atomic_signal_fence``.

Writing a wrapper around stdatomic.h would take probably 2 hours. You don't need to write any inline assembly, its already done in core.atomic. But realistically all you're doing is changing some names and order of parameters with slightly different types.

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.

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.

For ldc and gdc core.atomic already uses the backend intrinsics. It is only dmd that doesn't do that and hence does bad things.

Whatever is missing that stdatomic.h needs, should be added.

https://github.com/ldc-developers/ldc/blob/master/runtime/druntime/src/core/internal/atomic.d#L24

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

On 11/14/2023 12:51 AM, Richard (Rikki) Andrew Cattermole wrote:
> Question: Why do people want another wrapper around some inline assembly that already exists in core.atomic?

Because they have existing carefully crafted code in C and want to translate it to D.


> Writing a wrapper around stdatomic.h would take probably 2 hours.

Great! That saves each stdatomic C user 2 hours who wants to get their code in D.