Core.atomic: Fencing?

[Iain Buclaw]

== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> On Apr 8, 2011, at 8:07 AM, dsimcha wrote:
> > Are all atomic functions in core.atomic going to be guaranteed to act
> as full
> > memory barriers when it's ported to non-x86 architectures?
> std.parallelism
> > assumes that atomic instructions act as full barriers.  This is
> correct on
> > x86/x86, since loads and stores cannot be reordered with locked
> instructions,
> > and everything in the x86/x64 implementation of core.atomic uses the
> lock
> > prefix.  Are similar guarantees going to be made on other
> architectures?
> Yes.  The default behavior of core.atomic will be to produce no
> unexpected results.  I may expose some routines that allow the user to
> explicitly request weaker guarantees if available, but this shouldn't
> impact anyone calling core.atomic routines without the additional
> parameter.

On top of that, GCC targets will (*WIP*) be using builtin atomic load/cas routines
for architectures that support. And I'm pretty certain LDC does the same (I
believe it's implemented in Tango).

Regards