OpenMP中循环外定义的变量默认shared，易引发数据竞争；循环索引变量（如i）在3.0+版本中默认private。常见错误包括shared累加器未用reduction、vector多线程push_back未隔离、标志位被多线程覆盖。
OpenMP 循环并行里哪些变量默认 shared，哪些容易误成 shared 导致数据竞争
在 #pragma omp parallel for 中，循环外定义的变量默认是 shared，包括指针、对象、数组名——但它们指向的内容不自动共享或受保护。最容易出问题的是：循环体内修改了 shared 变量的值（比如累加器、标志位、容器 push_back），而没显式声明 private 或用 reduction。
常见错误现象：sum 累加结果每次运行不一致；std::vector 在多线程 push_back 时崩溃；int flag = 0; 被多个线程同时写成 1，逻辑错乱。
-
for循环索引变量（如i）在 OpenMP 3.0+ 中默认private，无需额外声明 - 函数参数、局部变量在每个线程栈上天然隔离，但若它们引用了外部
shared内存（如通过指针或引用传入），仍会触发竞争 - 类成员变量总是
shared（除非在 parallel 区内重新声明为private）
什么时候必须用 private，什么时候该用 reduction
private 是“每人一份副本”，适合中间计算、临时缓存、避免冲突的局部状态；reduction 是“每人算一部分，最后安全合并”，专用于可结合操作（+, *, &&, ||, min, max 等）的标量归约。
别把 reduction 当万能药：它只支持特定运算符，且要求初值符合结合律和交换律；对 std::vector 或自定义结构体不能直接用。
立即学习“C++免费学习笔记（深入）”；
- 用
private(i, temp_val)：当temp_val只在本轮迭代内使用，不跨线程传递 - 用
reduction(+:sum)：替代shared sum; #pragma omp atomic sum += x;，性能更好也更安全 - 错误用法：
reduction(+:vec)编译失败；reduction(&&:flag)虽语法合法，但若初始flag=true，任意一个线程算出false就会让最终结果为false，这未必是你想要的语义
shared 变量真要改，除了 atomic 还有哪些更稳的选择
#pragma omp atomic 只保单条读-改-写原子性（如 ++i, x += y），不防伪共享（false sharing）、不保证顺序、不适用于复杂操作（如插入 map、调用非原子函数）。真要共享写，优先考虑：
- 改用
reduction—— 最轻量、编译器优化充分 - 用
firstprivate+ 手动合并：每个线程持有一份容器副本，循环结束后在主线程合并（适合std::vector收集结果） - 加锁（
#pragma omp critical或omp_lock_t）：开销大，仅当必须串行访问某资源时用（如日志输出、文件写入） - 避免共享写：把“写共享”转为“写私有 + 一次汇总”，例如预分配数组，用循环索引直接写入对应位置，最后再 scan 或 reduce
注意：critical 块不按线程 ID 排序，多个线程可能卡在同一段代码，实测性能常比 atomic 还差。
调试数据竞争最实用的三招
OpenMP 自身不报数据竞争，得靠工具和习惯。别等崩溃了再查。
- 编译时加
-fsanitize=thread（Clang/GCC）：跑一遍就能暴露绝大多数竞态，报错精确到行和变量名 - 用
OMP_WAIT_POLICY=passive运行：减少忙等待干扰，让竞态更容易复现 - 临时关闭并行：
export OMP_NUM_THREADS=1，对比结果是否一致——如果单线程正确、多线程错误，基本锁定是共享问题而非算法逻辑问题
真正麻烦的是那些“看似稳定”的竞态：只在高负载、特定 CPU 核心组合、特定内存对齐下触发。所以只要涉及共享写，就别依赖“我试了几次都对”。
