Ah, so I guess we don't need a barrier at all on x86 for the release
semantics.
Presumably we still need something for Dekker-style algorithms, although I
don't think we use those anywhere in the stdlib, at least.
I guess it's just a question of which is faster?
On Tue, Apr 28, 2020 at 8:24 PM
On x86-TSO model, it seems that we don't need any mfence to archive
acquire-release semantics. Acquire-release semantics only need compiler
barrier to prevent compiler reordering, see https://godbolt.org/z/7JcX-d .
在 2020年4月29日星期三 UTC+8上午7:42:26，keith@gmail.com写道：
>
> It looks like the
It looks like the mechanism used by C's std::atomic would not be useful for
us.
We require release semantics on atomic stores. That is, if one thread does:
.. some other writes ...
atomic.StoreInt32(p, 1)
and another thread does
if atomic.LoadInt32(p) == 1 {
.. some other reads ...
}
If
But on gcc 9.3, atomic store with seq_cst order, will be compiled to
mov+fence rather than xchg, see https://gcc.godbolt.org/z/ucbQt6 . Why do
we use xchg rather than mov+fence in Go?
在 2020年4月28日星期二 UTC+8上午7:26:15，Ian Lance Taylor写道：
>
> On Sun, Apr 26, 2020 at 1:31 AM Cholerae Hu > wrote:
>
On Sun, Apr 26, 2020 at 1:31 AM Cholerae Hu wrote:
>
> Atomic.StoreX doesn't return the old value of the given pointer, so lock mov
> would work. Why do we use a xchg instead? It there any performance issue?
I assume that you are talking about Intel processors. Intel
processors do not have a
