OpenMP for循环添加critical临界区后仍存在竞态条件问题排查

我在多线程运行程序时出现了不可预测的错误，尝试通过插入临界区定位问题来源，目前编写的测试代码如下：

void A::func()
{
 #pragma omp parallel for
 for (int i=0; i<100; ++i)
  {
    #pragma omp critical
    results[i] = compute(i);
  }
}

上述代码仍然复现我要排查的问题，唯一能让问题消失的方案是取消for循环的并行化，这显然不符合使用需求。

注意compute函数逻辑较为复杂，内部用到了一些缓存机制，我不排除这段代码本身存在问题，但现在循环内的逻辑已经全部被critical临界区包裹，我无法理解问题出现的原因。

我正在调试的实际for循环代码是STIR库的ScatterSimulation.cxx文件179-198行，仍存在问题的测试版本和上方示例逻辑接近。

备注：我最初在更复杂的场景下发过相关提问，现已删除原技术社区帖子，原因有二：一是我当时给出的简单示例无法复现问题，二是当前场景的问题更令人费解。

补充信息：我的测试环境为搭载锐龙9 5900处理器的Windows 10系统，在WSL2/Ubuntu 20.04上使用gcc-8、gcc-9编译运行时会偶发问题，在Windows上用VS 2019、WSL2/Ubuntu 20.04上用clang-13编译运行时未观测到问题，但这不能说明问题不存在。

• 你当前的写法已经将循环体完全串行化，和取消并行的唯一差异只有多线程创建销毁开销、线程上下文环境的区别，因此问题必然出在和执行顺序无关、只和多线程执行环境相关的逻辑中，和临界区的同步逻辑无关。
• 优先排查compute函数内部实现：
  • 检查是否存在未初始化的局部栈变量：多线程栈内存的初始脏值和串行执行时不同，脏值的差异可能导致偶发异常，这也符合不同编译器、不同环境下表现不一致的特征。
  • 检查内部缓存的实现：如果缓存使用了thread_local修饰，gcc 8/9版本对OpenMP线程的thread_local变量初始化存在已知缺陷，会出现偶发的初始化异常，而clang和MSVC无此问题，完全匹配你观测到的编译环境差异。如果是全局/类共享缓存，确认在并行区域启动前已经完成完整初始化，避免跨线程的内存可见性问题。
  • 检查compute是否调用了线程不安全的系统函数/第三方库函数，部分旧版本的库函数在多线程环境下调用会出现偶发异常。
• 排查results数组的合法性：确认数组指针有效、分配长度足够，不存在越界访问、野指针、未对齐内存访问等问题，串行执行时的内存布局可能刚好掩盖这些问题，多线程的内存布局变化会触发异常。
• 可尝试以下调试手段快速定位问题：
  • 给临界区指定唯一名称，如#pragma omp critical(scatter_sim_crit)，避免和代码其他位置的无名临界区产生意外冲突。
  • 将#pragma omp parallel for改为仅创建并行区域，内部手动写串行for循环，若仍能复现问题则完全排除循环调度逻辑的影响，直接锁定并行区域本身的问题。
  • 用gcc的-fsanitize=thread参数编译运行程序，线程 sanitizer会直接定位到所有未同步的跨线程数据竞争，哪怕是发生在compute内部的隐式竞争也能被捕获。

内容的提问来源于stack exchange，提问作者krthie