First of all, look into $IPPROOTdocThreadedFunctionsList.txt file to determine if your functions are internally threaded, or not.
Supposing they're threaded, you need to use either dynamic linking to IPP dynamic libraries, or use static linking to libraries with suffix "_t". Only these kinds of linking provide function threading.
This is similar to the question I asked yesterday.
I believe this is the case, but I'd like for someone to please verify ....
If the function is not on the Threaded Functions list, then that function does not take advantage of multiple threads. However, you should still be able to call the non-threaded IPP functions from your multiple threads ... the functions themselvesshould be thread-safe, just not multi-threaded. This suggests that these functions will block, thus perhaps reducing any gains realized from multithreading in your application (depending on your design).
For example, I'm calling the IPP alpha compositing function from separate threads. The function works correctly, but each call blocks, thus serializing my threads.
IPP functions are desinged to be thread safe, so you can run IPP functions in parallel in different threads in your application. And of courseIPP functions itself do not block your threads.
Thanks for clarifying. Are you certain the non-threaded IPP functions do not block? Do some of them not protect system resources with mutexes or semaphores?
I have a simple test application with mutliple threads spanning multiple processor cores, accessing a single non-threaded IPP function, and my test data suggests that the function call disallows parallel execution across these multiple threads/cores. Perhaps the problem is in my thread creation or data creation in relation to the Intel IPP model?
Any guidance is most appreciated.