在已经多线程的应用程序中使用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:我们的问题是：

( a)在不同线程的上下文中使用omp时，是否存在重用openmp线程的方法？

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

( c)对于第一个并行块如此缓慢的现象(即使在活动模式下等待)，有什么合理的解释吗？

Upd2:请注意，这个问题可能与GNU实现有关。国际刑事法院没有。

Answer 1

尝试使用omp_set_num_threads(1)和omp_set_num_threads(cpucount)在运行时启动/停止openmp线程

这个使用(1)的调用应该停止所有openmp工作线程，并且调用with (cpu_num)将再次重新启动它们。

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

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

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