• dsimcha (6/6) Apr 08 2011 Are all atomic functions in core.atomic going to be guaranteed to act as...
• Sean Kelly (12/18) Apr 08 2011 std.parallelism
• Iain Buclaw (5/23) Apr 08 2011 On top of that, GCC targets will (*WIP*) be using builtin atomic load/ca...
• dsimcha (3/7) Apr 08 2011 I assume the implication is that the GCC builtin atomics act as full bar...
• Iain Buclaw (3/10) Apr 08 2011 All sync builtins are described as full barriers. Non-traditional locks ...
• Iain Buclaw (7/14) Apr 09 2011 You can see:

dsimcha <dsimcha yahoo.com> writes:

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?

Sean Kelly <sean invisibleduck.org> writes:

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.=

Iain Buclaw <ibuclaw ubuntu.com> writes:

== Quote from Sean Kelly (sean 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

dsimcha <dsimcha yahoo.com> writes:

== Quote from Iain Buclaw (ibuclaw ubuntu.com)'s article
 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

I assume the implication is that the GCC builtin atomics act as full barriers on
all architectures?

Iain Buclaw <ibuclaw ubuntu.com> writes:

== Quote from dsimcha (dsimcha yahoo.com)'s article
 == Quote from Iain Buclaw (ibuclaw ubuntu.com)'s article
 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

 I assume the implication is that the GCC builtin atomics act as full barriers
on
 all architectures?

All sync builtins are described as full barriers. Non-traditional locks are
acquire or release barriers.

Iain Buclaw <ibuclaw ubuntu.com> writes:

== Quote from dsimcha (dsimcha yahoo.com)'s article
 == Quote from Iain Buclaw (ibuclaw ubuntu.com)'s article
 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

 I assume the implication is that the GCC builtin atomics act as full barriers
on
 all architectures?

You can see:

https://bitbucket.org/goshawk/gdc/src/1a74f184e2d8/d/phobos2/gcc/atomics.d
https://bitbucket.org/goshawk/gdc/src/8f5627ca0ba5/d/druntime/core/atomic.d#cl-703

For the implementation if you have any further pondering about it (you
mentioning
it has made me finally gotten round to putting it in place. :)

Regards