在C 11中是否有任何编译器屏障等于asm(“”:::“memory”)？

我的测试代码如下,我发现只有memory_order_seq_cst禁止编译器重新排序.

#include <atomic>

using namespace std;

int A, B = 1;

void func(void) {
    A = B + 1;
    atomic_thread_fence(memory_order_seq_cst);
    B = 0;
}

而诸如memory_order_release,memory_order_acq_rel等其他选择根本不会产生任何编译器障碍.

我认为他们必须使用原子变量,如下所示.

#include <atomic>

using namespace std;

atomic<int> A(0);
int B = 1;

void func(void) {
    A.store(B+1, memory_order_release);
    B = 0;
}

但我不想使用原子变量.与此同时,我认为“asm(”“:::”记忆“)”太低了.

还有更好的选择吗？

解决方法:

re：你的编辑：

But I do not want to use atomic variable.

为什么不？如果出于性能原因,将它们与memory_order_relaxed和atomic_signal_fence(mo_whatever)一起使用来阻止编译器重新排序,除了编译器屏障可能阻止某些编译时优化之外没有任何运行时开销,具体取决于周围的代码.

如果出于其他原因,那么atomic_signal_fence可能会为您提供恰好在目标平台上运行的代码.我怀疑它确实订购了非原子<>加载和/或存储,因此它甚至可以帮助避免C中的数据争用未定义行为.

什么足够？

无论有任何障碍,如果两个线程同时运行此函数,则由于对非原子<>的并发访问,您的程序具有未定义的行为.变量.因此,如果您正在讨论与在同一线程中运行的信号处理程序同步,则此代码有用的唯一方法.

这也与要求“编译器障碍”一致,只是为了防止在编译时重新排序,因为无序执行和内存重新排序总是保留单个线程的行为.因此,您永远不需要额外的屏障指令来确保按程序顺序查看自己的操作,您只需要在编译时停止编译器重新排序.见Jeff Preshing的帖子：Memory Ordering at Compile Time

这就是atomic_signal_fence的用途.您可以将它与任何std :: memory_order一起使用,就像thread_fence一样,以获得不同的屏障优势,并且只能阻止您需要防止的优化.

… atomic_thread_fence(memory_order_acq_rel) did not generate any compiler barrier at all!

在几个方面完全错了.

atomic_thread_fence是一个编译器障碍,加上我们的加载/存储对其他线程可见的顺序限制重新排序所需的任何运行时障碍.

我猜你的意思是当你查看x86的asm输出时它没有发出任何障碍指令.像x86的MFENCE这样的指令不是“编译器障碍”,它们是运行时内存屏障,甚至阻止StoreLoad在运行时重新排序. (这是x86允许的唯一重新排序.只有在使用弱排序(NT)存储时才需要SFENCE和LFENCE,如MOVNTPS (_mm_stream_ps).)

在像ARM这样弱有序的ISA上,thread_fence(mo_acq_rel)不是免费的,而是编译成一条指令. gcc5.4使用dmb ish. (见Godbolt compiler explorer).

编译器屏障只是在编译时阻止重新排序,而不必阻止运行时重新排序.因此,即使在ARM上,atomic_signal_fence(mo_seq_cst)也会编译为无指令.

一个足够弱的屏障允许编译器在商店之前将商店存储到A(如果需要),但gcc碰巧决定仍然按源顺序执行它们,即使使用thread_fence(mo_acquire)(不应该与其他商店订购商店)商店).

所以这个例子并没有真正测试某些东西是否是编译器障碍.

来自gcc的奇怪编译器行为与编译器障碍不同的示例：

See this source+asm on Godbolt.

#include <atomic>
using namespace std;
int A,B;

void foo() {
  A = 0;
  atomic_thread_fence(memory_order_release);
  B = 1;
  //asm volatile(""::: "memory");
  //atomic_signal_fence(memory_order_release);
  atomic_thread_fence(memory_order_release);
  A = 2;
}

这会以你期望的方式编译clang：thread_fence是StoreStore屏障,因此A = 0必须在B = 1之前发生,并且不能与A = 2合并.

    # clang3.9 -O3
    mov     dword ptr [rip + A], 0
    mov     dword ptr [rip + B], 1
    mov     dword ptr [rip + A], 2
    ret

但是对于gcc,屏障没有效果,只有A的最终存储在asm输出中.

    # gcc6.2 -O3
    mov     DWORD PTR B[rip], 1
    mov     DWORD PTR A[rip], 2
    ret

但是使用atomic_signal_fence(memory_order_release),gcc的输出匹配clang.因此atomic_signal_fence(mo_release)具有我们期望的屏障效果,但是任何弱于seq_cst的atomic_thread_fence都不会充当编译屏障.

这里的一个理论是gcc知道它是多个线程写入非原子<>的官方未定义行为.变量.这并没有多少水,因为如果用于与信号处理程序同步,atomic_thread_fence仍然可以工作,它只是比必要的强.

BTW,使用atomic_thread_fence(memory_order_seq_cst),我们得到了预期的结果

    # gcc6.2 -O3, with a mo_seq_cst barrier
    mov     DWORD PTR A[rip], 0
    mov     DWORD PTR B[rip], 1
    mfence
    mov     DWORD PTR A[rip], 2
    ret

即使只有一个屏障,我们也可以得到这个,这仍然允许A = 0和A = 2存储一个接一个地发生,因此允许编译器跨屏障合并它们. (观察者未能看到单独的A = 0和A = 2值是可能的排序,因此编译器可以决定总是会发生什么).但是,当前的编译器通常不会进行这种优化.请参阅我在Can num++ be atomic for ‘int num’?的答案结尾处的讨论.

标签：lock-free,memory-barriers,c,c11,atomic
来源： https://codeday.me/bug/20190823/1702448.html