| commit | 3bbf572345c65813f86a8fc434ea1b23beb08e16 | |
| author | Paolo Bonzini <pbonzini@redhat.com> | |
| Wed, 3 Jun 2015 12:21:20 +0000 (3 14:21 +0200) | ||
| committer | Paolo Bonzini <pbonzini@redhat.com> | |
| Fri, 5 Jun 2015 17:45:13 +0000 (5 19:45 +0200) | ||
| tree | 4f8406def84b0edf4787aef5ffedaf4529c228e9 | treesnapshot (tar.gz zip) |
| parent | 11e66a15a084cb0820dba13f4ea3b15b0512fd39 | commitdiff |
atomics: add explicit compiler fence in __atomic memory barriers
__atomic_thread_fence does not include a compiler barrier; in the
C++11 memory model, fences take effect in combination with other
atomic operations. GCC implements this by making __atomic_load and
__atomic_store access memory as if the pointer was volatile, and
leaves no trace whatsoever of acquire and release fences in the
compiler's intermediate representation.
In QEMU, we want memory barriers to act on all memory, but at the same
time we would like to use __atomic_thread_fence for portability reasons.
Add compiler barriers manually around the __atomic_thread_fence.
Message-Id: <1433334080-14912-1-git-send-email-pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
__atomic_thread_fence does not include a compiler barrier; in the
C++11 memory model, fences take effect in combination with other
atomic operations. GCC implements this by making __atomic_load and
__atomic_store access memory as if the pointer was volatile, and
leaves no trace whatsoever of acquire and release fences in the
compiler's intermediate representation.
In QEMU, we want memory barriers to act on all memory, but at the same
time we would like to use __atomic_thread_fence for portability reasons.
Add compiler barriers manually around the __atomic_thread_fence.
Message-Id: <1433334080-14912-1-git-send-email-pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| include/qemu/atomic.h | diffblobblamehistory |