www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Core.atomic: Fencing?

reply 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?
Apr 08 2011
parent reply 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 =

 memory barriers when it's ported to non-x86 architectures?  =

 assumes that atomic instructions act as full barriers.  This is =

 x86/x86, since loads and stores cannot be reordered with locked =

 and everything in the x86/x64 implementation of core.atomic uses the =

 prefix.  Are similar guarantees going to be made on other =

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.=
Apr 08 2011
parent reply 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

 memory barriers when it's ported to non-x86 architectures?

 assumes that atomic instructions act as full barriers.  This is

 x86/x86, since loads and stores cannot be reordered with locked

 and everything in the x86/x64 implementation of core.atomic uses the

 prefix.  Are similar guarantees going to be made on other

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
Apr 08 2011
parent reply 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?
Apr 08 2011
next sibling parent 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

all architectures?

All sync builtins are described as full barriers. Non-traditional locks are acquire or release barriers.
Apr 08 2011
prev sibling parent 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

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
Apr 09 2011