On 11/14/12 8:59 AM, David Nadlinger wrote:
On Wednesday, 14 November 2012 at 14:32:34 UTC, Andrei Alexandrescu wrote:
On 11/14/12 4:23 AM, David Nadlinger wrote:
On Wednesday, 14 November 2012 at 00:04:56 UTC, deadalnix wrote:
That is what java's volatile do. It have several uses cases, including
valid double check locking (It has to be noted that this idiom is used
incorrectly in druntime ATM, which proves both its usefullness and
that it require language support) and disruptor which I wanted to
implement for message passing in D but couldn't because of lack of
support at the time.
What stops you from using core.atomic.{atomicLoad, atomicStore}? I don't
know whether there might be a weird spec loophole which could
theoretically lead to them being undefined behavior, but I'm sure that
they are guaranteed to produce the right code on all relevant compilers.
You can even specify the memory order semantics if you know what you are
doing (although this used to trigger a template resolution bug in the
frontend, no idea if it works now).
David
This is a simplification of what should be going on. The
core.atomic.{atomicLoad, atomicStore} functions must be intrinsics so
the compiler generate sequentially consistent code with them (i.e. not
perform certain reorderings). Then there are loads and stores with
weaker consistency semantics (acquire, release, acquire/release, and
consume).
Sorry, I don't quite see where I simplified things.
First, there are more kinds of atomic loads and stores. Then, the fact
that the calls are not supposed to be reordered must be a guarantee of
the language, not a speculation about an implementation. We can't argue
that a feature works just because it so happens an implementation works
a specific way.
Yes, in the
implementation of atomicLoad/atomicStore, one would probably use
compiler intrinsics, as done in LDC's druntime, or inline assembly, as
done for DMD.
But an optimizer will never move instructions across opaque function
calls, because they could have arbitrary side effects.
Nowhere in the language definition is explained what an opaque function
call is and what optimizations can and cannot be done in the presence of
such.
So, either we are
fine by definition,
s/definition/happenstance/
or if the compiler inlines the
atomicLoad/atomicStore calls (which is actually possible in LDC), then
its optimizer will detect the presence of inline assembly resp. the
load/store intrinsics, and take care of not reordering the instructions
in an invalid way.
I don't see how this makes my answer to deadalnix (that »volatile« is
not necessary to implement sequentially consistent loads/stores) any
less valid.
Using load/store everywhere would make volatile unneeded (and for us,
shared). But the advantage there is that you qualify the type/value once
and then you don't need to remember to only use specific primitives to
manipulate it.
Andrei
