c++, calling opencv from multiple threads

asked 2018-05-17 09:52:47 -0500


i have a highly parallel problem: run solvePnP() on several thousand independent input datasets.

Using a single c++ pthread to call the lib is only using a small part of the CPU cores available. IPP / TBB / whatever else opencv uses seem to be limited in the number of CPU cores used per dataset for this problem and input datasets.

Using #CPU pthreads is faster overall, but also hits a limit at around 3 threads: something in the lib seems to lock a global critical section.

Is it possible to get around this critical section without running multiple processes? Which compile time options are relevant here?

I'm currently using the OpenCV 3.4.1 Windows Pack, but i'm flexible.


edit retag flag offensive close merge delete


Just a question.... are you aware of the C++ threads? It's part of the standard now. I've used it for a network server app, and the std::mutex is great for mutual exclusion between threads (including the main thread). Each thread communicated with the main thread using a vector<string>, kind of like a log. All of these objects are passed into the thread function as parameters.

sjhalayka gravatar imagesjhalayka ( 2018-05-17 10:46:31 -0500 )edit

Yes, but my toolchain uses pthreads to realise c++11 threads. All the nice c++11 stuff works based on pthreads ...

l.gilson gravatar imagel.gilson ( 2018-05-17 11:36:01 -0500 )edit

setNumThread doc "I'm currently using the OpenCV 3.4.1 Windows Pack, but i'm flexible." You should build opencv using cmake

LBerger gravatar imageLBerger ( 2018-05-17 13:40:23 -0500 )edit

I tested setNumThreads(0) and (1) and also recompiled excluding IPP and TBB: concurrently calling solvePnP() still hints at a global critical section. Using several processes concurrently is faster than using threads of any type. Using disjunct processes is inconvenient for my usecase, but doable.

I'm still open for ideas.

l.gilson gravatar imagel.gilson ( 2018-05-22 02:40:28 -0500 )edit