我在商业应用程序中使用 OpenCV，并且没有购买 TBB 许可的管理权限，所以我使用 OpenMP 作为并行框架构建了 OpenCV。
我们用作实时处理的帧源的所有机器视觉相机都有 SDK，它们用数据填充循环队列中的帧缓冲区，并调用用户提供的回调以在 SDK 自己的线程池的线程中同时处理它们.
这在不考虑 OpenMP 时工作正常，因为我在通过线程间缓冲区将它们序列化之前对单个帧进行了一堆(无内存)处理，以馈送到需要按顺序处理帧的有状态处理阶段。如果只是并发帧处理，那么我根本不需要 OpenMP；但是，我需要在 OpenCV 中启用它，以便也可以加速有序帧处理。
我担心的是，当 OpenMP 在第一阶段使用时，我可以期望它在多大程度上工作，在相机 SDK 显式创建的线程中同时执行的回调。当在多个外部创建的线程中触发并行区域时，我是否可以假设 OpenMP 运行时足够智能以有效地使用其线程池？
该平台保证为 x86-64(VC++15 或 GCC)。
最佳答案
情况
如果我正确理解了这个问题，您正在使用的相机库将产生许多线程，每个线程都会调用您的回调函数。在您的回调中，您想使用 OpenMP 来加速该处理。其结果通过某个线程间 channel 发送到执行更多处理的线程管道。
如果这是错误的，请忽略此答案的其余部分!
其余答案
在回调中使用 OpenMP 似乎会将应用程序这部分的计算负载切成小块，而没有太多好处。相机库已经与帧的处理重叠。在这里使用 OpenMP 意味着帧的处理实际上并没有重叠(但是相机库仍然像使用多个线程一样)。
如果它仍然重叠，那么从逻辑上讲，您的系统中没有足够的内核来跟上整体工作负载(假设您使用 OpenMP 导致所有内核被最大化处理单个帧)......我' m 假设您的系统成功地跟上帧流，并且必须有足够的 grunt 才能做到这一点。
所以，我认为 OpenMP 在使用它的线程池时是否智能并不是一个真正的问题。线程池将专用于处理单个帧，它会在下一帧到达之前完成。
非重叠确实意味着延迟较低，这可能是您想要的。但是，如果相机库使用 OpenMP 将单个线程与您的回调一起使用(并负责在下一帧到达之前完成)，您可以实现相同的目标。随着更少的线程上下文切换发生，它甚至会更快一点。因此，如果您可以阻止库生成所有这些线程(可能有一个配置参数、环境变量或它的 API 的其他部分)，那么它可能是值得的。
关于multithreading - 使用 OpenCV 时的 OpenMP 和显式线程互操作性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45260686/