在已经多线程的应用程序中使用OpenMP（libgomp）

Question

我们使用OpenMP（libgomp）来加速多线程Qt应用程序中的一些计算。并行OpenMP部分位于两个不同的线程中，但实际上它们并不会并行执行。我们在这种情况下观察到的是2N（其中N = OMP_THREAD_LIMIT）omp线程启动，显然互相干扰。计算时间非常长，而处理器负载很低。设置OMP_WAIT_POLICY几乎没有任何影响。

我们也尝试将所有omp节移到单个线程中（但从架构的角度来看，这不是一个好的解决方案）。在这种情况下，整体计算时间确实会下降并且处理器已满载，但前提是OMP_WAIT_POLICY设置为ACTIVE。当OMP_WAIT_POLICY == PASSIVE时，计算时间保持较低，处理器空闲50％的时间。

奇怪的是，当我们在单线程中使用omp时，与多线程情况相比，使用omp（在一系列omp计算中）并行化的第一个循环执行速度要慢10倍。

UPD：我们的问题是：

一）有没有办法在不同的线程的上下文中使用OMP时，重用OpenMP的线程。

b）为什么使用OMP_WAIT_POLICY == PASSIVE执行会减慢一切。唤醒线程需要很长时间吗？

c）是那里的第1并联块的速度比较慢（即使在主动模式下等待时）

UPD2的现象，任何合乎逻辑的解释：请注意该问题可能与GNU OMP实施。 icc没有它。

Answer 1

尝试使用omp_set_num_threads(1)和omp_set_num_threads(cpucount)

此调用与(1)应停止所有的OpenMP工作线程开始运行时/停止OpenMP的线程，并与（cpu_num）调用将再次重新启动它们。

因此，在程序开始时，运行omp_set_num_threads(1)。 在omp并行化区域之前，即使使用WAIT_POLICY=active也可以启动omp线程，并且在此之前它们不会消耗CPU。

在omp并行区域之后，您可以再次停止线程。

omp_set_num_threads(cpucount)调用非常慢，比用wait_policy = passive唤醒线程要慢。这可能是（c）的原因 - 如果你的libgomp只在第一个并行区域启动线程。