根据OpenMP规范(v4.0),由于i
的不同步读/写,以下程序包含可能的数据争用:
int i{0}; // std::atomic<int> i{0};
void write() {
// #pragma omp atomic write // seq_cst
i = 1;
}
int read() {
int j;
// #pragma omp atomic read // seq_cst
j = i;
return j;
}
int main() {
#pragma omp parallel
{ /* code that calls both write() and read() */ }
}
我想到的可能解决方案在代码中显示为注释:
i
,#pragma omp atomic write/read
的写入和读取
i
,#pragma omp atomic write/read seq_cst
的写入和读取
std::atomic<int>
代替int
作为i
的类型。以下是编译器生成的x86_64指令(在所有情况下均为-O2
):
GNU g++ 4.9.2: i = 1; j = i;
original code: MOV MOV
#pragma omp atomic: MOV MOV
// #pragma omp atomic seq_cst: MOV MOV
#pragma omp atomic seq_cst: MOV+MFENCE MOV (see UPDATE)
std::atomic<int>: MOV+MFENCE MOV
clang++ 3.5.0: i = 1; j = i;
original code: MOV MOV
#pragma omp atomic: MOV MOV
#pragma omp atomic seq_cst: MOV MOV
std::atomic<int>: XCHG MOV
Intel icpc 16.0.1: i = 1; j = i;
original code: MOV MOV
#pragma omp atomic: * *
#pragma omp atomic seq_cst: * *
std::atomic<int>: XCHG MOV
* Multiple instructions with calls to __kmpc_atomic_xxx functions.
我想知道为什么GNU / clang编译器不会为#pragma omp atomic
写入生成任何特殊指令。我期望与std::atomic
类似的说明,即MOV+MFENCE
或XCHG
。有什么解释吗?
更新
g ++ 5.3.0为MFENCE
生成#pragma omp atomic write seq_cst
。我相信这是正确的行为。如果没有seq_cst
,它会生成普通MOV
,这对于非SC原子性就足够了。
我的Makefile中有一个错误,g ++ 4.9.2也为CS原子写入产生MFENCE
。对不起,伙计们。
Clang 3.5.0没有实现OpenMP SC原子,感谢Hristo Iliev指出这一点。
答案 0 :(得分:1)
有两种可能性。
编译器没有义务将包含数据争用的C ++代码转换为错误的机器代码。根据机器内存模型,通常使用的指令可能已经是原子的和连贯的。将相同的C ++代码带到另一个体系结构中,您可能会开始看到pragma导致x86_64上不存在的差异。
除了可能导致使用不同的指令和/或额外的内存栅栏指令之外,原子编译指示(以及std::atomic
和volatile
)也会限制编译器自己的代码重新排序优化。它们可能不适用于您的简单情况,但您当然可以看到共同子表达式消除,包括在循环外提升计算,可能会受到影响。