core.thread currently uses atomicStore!(MemoryOrder.raw) as a combined volatile store and barrier for other stores: https://github.com/D-Programming-Language/druntime/blob/3626a88e1dee58a88969f6bbfc5a1b1c74d0dee5/src/core/thread.d#L4599-L4612.
This only incidentally works with DMD, as atomicStore can not be inlined there. Neither atomicStore (with any ordering) nor the proposed volatileStore can be used to fix that code, as they only affect ordering with regard to other atomic or volatile operations, and not the other plain assignments.
atomicFence() would work to fix the problem, but would be much too heavy-handed, as we don't need any thread synchronization at all, just asynchronous signal safety. We really need something like C++'s std::atomic_signal_fence in druntime. DMD can just ignore it, if its optimizer doesn't reorder loads/stores anyway.
Comment #1 by robert.schadek — 2024-12-13T18:22:34Z