[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
amacleod at redhat dot com
Thu Apr 16 12:25:00 GMT 2015
--- Comment #34 from Andrew Macleod <amacleod at redhat dot com> ---
> However, I guess some people relying on data races in their programs could
> (mis?)understand the __sync_lock_release semantics to mean that it is a
> means to get the equivalent of a C11 release *fence* -- which it is not
> because the fence would apply to the (erroneously non-atomic) store after
> the barrier, which could one lead to believe that if one observes the store
> after the barrier, the fence must also be in effect. Thoughts?
before we get too carried away, maybe we should return to what we *think*
__sync are suppose to do. It represents a specific definition by intel.. From
the original documentation for __sync "back in the day", and all legacy uses of
sync should expect this behaviour:
"The following builtins are intended to be compatible with those described
in the "Intel Itanium Processor-specific Application Binary Interface",
section 7.4. As such, they depart from the normal GCC practice of using
the ``__builtin_'' prefix, and further that they are overloaded such that
they work on multiple types."
The definition of "barrier" from that documentation is :
acquire barrier : Disallows the movement of memory references to visible data
from before the intrinsic (in program order) to after the intrinsic (this
behavior is desirable at lock-release operations, hence the name).
release barrier: Disallows the movement of memory references to visible data
from after the intrinsic (in program order) to before the intrinsic (this
behavior is desirable at lock-acquire operations, hence the name).
full barrier: disallows the movement of memory references to visible data past
the intrinsic (in either direction), and is thus both an acquire and a release
barrier. A barrier only restricts the movement of memory references to visible
data across the intrinsic operation: between synchronization operations (or in
their absence), memory references to visible data may be freely reordered
subject to the usual data-dependence constraints.
Caution: Conditional execution of a synchronization intrinsic (such as within
an if or a while statement) does not prevent the movement of memory references
to visible data past the overall if or while construct.
More information about the Gcc-bugs