# At a local mysql-5.5-bugteam repository of davi
3142 Davi Arnaut 2010-11-30
Bug#56760: my_atomics failures on osx10.5-x86-64bit
The problem was due to a misuse of GCC asm constraints used to
implement a atomic load. On x86_64, the load was implemented
as a cmpxchg which implicitly uses the eax register as a
source and destination operand, yet the dummy value used for
comparison wasn't being properly loaded into eax (and other
The core problem is that cmpxchg is unnecessary as a load
on x86_64 as there are other simpler instructions such
as xadd. Even though, such instructions are only used to
have a memory barrier as load and stores are atomic by
definition. Hence, the solution is to explicitly issue the
required CPU and compiler barriers.
Issue a synchronizing instruction before loading the value.
Afterwards, issue a compiler barrier to prevent reordering.
=== modified file 'include/atomic/x86-gcc.h'
--- a/include/atomic/x86-gcc.h 2010-09-17 20:34:15 +0000
+++ b/include/atomic/x86-gcc.h 2010-11-30 14:20:46 +0000
@@ -78,15 +78,15 @@
- Actually 32-bit reads/writes are always atomic on x86
- But we add LOCK_prefix here anyway to force memory barriers
+ Actually 32/64-bit reads/writes are always atomic on x86_64,
+ nonetheless issue memory barriers as appropriate.
#define make_atomic_load_body(S) \
- ret=0; \
- asm volatile (LOCK_prefix "; cmpxchg %2, %0" \
- : "=m" (*a), "=a" (ret) \
- : "r" (ret), "m" (*a) \
- : "memory")
+ /* Serialize preceding store operations. */ \
+ asm volatile ("sfence" ::: "memory"); \
+ ret= *a; \
+ /* Prevent compiler from reordering instructions. */ \
+ asm volatile ("": : :"memory")
#define make_atomic_store_body(S) \
asm volatile ("; xchg %0, %1;" \
: "=m" (*a), "+r" (v) \
Attachment: [text/bzr-bundle] email@example.com
|• bzr commit into mysql-5.5-bugteam branch (davi:3142) Bug#56760||Davi Arnaut||30 Nov|