Tim Blechmann wrote:
hi all,
i need another pair of eyes regarding boost.atomic on x86:
the implementation of memory barrier is merely a compiler barrier, but not a CPU barrier, as it is using code like: __asm__ __volatile__ ("" ::: "memory");
afaict, one should use a `real' CPU barrier like "mfence" or "lock; addl $0,0(%%esp)". is this correct?
Probably not, but can you please be more specific? In, f.ex. gcc-x86.hpp there are several functions that fit the description. Which one do you think is wrong?
apart from that, i've seen that compare_exchange is using explicit memory barriers before/after "cmpxchg" instructions. i somehow though that cmpxchg and the 8b/16b variants implicitly issue a memory barrier, so the resulting code would generate multiple memory barriers.
The locked instructions (and XCHG, which is implicitly locked) are indeed "memory barriers" from CPU point of view, but not necessarily from compiler point of view. The calls to platform_fence_before and platform_fence_after are there for the compiler barrier, as far as I can see.