Something needs to happen with shared, and soon.
David Nadlinger
see at klickverbot.at
Wed Nov 14 09:31:06 PST 2012
On Wednesday, 14 November 2012 at 15:08:35 UTC, Andrei
Alexandrescu wrote:
> Sorry, I was imprecise. We need to (a) define intrinsics for
> loading and storing data with high-level semantics (a short
> list: acquire, release, acquire+release, and
> sequentially-consistent) and THEN (b) implement the needed code
> generation appropriately for each architecture. Indeed on x86
> there is little need to insert fence instructions, BUT there is
> a definite need for the compiler to prevent certain
> reorderings. That's why implementing shared data operations
> (whether implicit or explicit) as sheer library code is NOT
> possible.
Sorry, I didn't see this message of yours before replying (the
perils of threaded news readers…).
You are right about the fact that we need some degree of compiler
support for atomic instructions. My point was that is it already
available, otherwise it would have been impossible to implement
core.atomic.{atomicLoad, atomicStore} (for DMD inline asm is
used, which prohibits compiler code motion).
Thus, »we«, meaning on a language level, don't need to change
anything about the current situations, with the possible
exception of adding finer-grained control to
core.atomic.MemoryOrder/mysnc [1]. It is the duty of the compiler
writers to provide the appropriate means to implement druntime on
their code generation infrastructure – and indeed, the
situation in DMD could be improved, using inline asm is hitting a
fly with a sledgehammer.
David
[1] I am not sure where the point of diminishing returns is here,
although it might make sense to provide the same options as
C++11. If I remember correctly, D1/Tango supported a lot more
levels of synchronization.
More information about the Digitalmars-d
mailing list