On 11/14/12 9:31 AM, David Nadlinger wrote:
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).

Yah, the whole point here is that we need something IN THE LANGUAGE DEFINITION about atomicLoad and atomicStore. NOT IN THE IMPLEMENTATION.

THIS IS VERY IMPORTANT.

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.

That is correct. My point is that compiler implementers would follow some specification. That specification would contain informationt hat atomicLoad and atomicStore must have special properties that put them apart from any other functions.

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.

We could start with sequential consistency and then explore riskier/looser policies.


Andrei

Reply via email to