Re: [boost] [atomic, x86] need another pair of eyes

Subject: Re: [boost] [atomic, x86] need another pair of eyes
From: Peter Dimov (lists_at_[hidden])
Date: 2012-12-19 06:17:58

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.