MKL concurrency (openMP?) with Visual Studio ppl

[Jens_E_]

Hi,

In my C++ applicaiton (Visual Studio 2017, with the MS compiler) I am using MKL extensively. In this particular case I am using cblas_dgemm from mkl.h.

I am also using the c++ std::thread library for threads doing jobs "on the side", and the Microsoft concurrency::parallel_for for higher level parallelization.

Today I was experimenting with the use of an std::condition_variable for detecting when a job in a detached std::thread has finished. This change caused a the application to hang indefinitely.

When debugging, the issue appears not related to my new change (i.e. the condition variable) but to intel mkl and cblas_dgemm. This seems weird to me. I do not believe in an issue with cblas_dgemm, or my use of it in this case, as it is a simple 3x3 matrix mulitplication. 

Therefore: are there any known issues with combining mkl (openMP?) with the MS threading model (ppl) in the same application?

I am using Intel Parallel studio XE2018 U4 Pro (with VS integration).

Jens

[Jens_E_]

Let me also add that my application does not use Open MP.

I am aware of this https://software.intel.com/content/www/us/en/develop/documentation/mkl-windows-developer-guide/top/linking-your-application-with-the-intel-math-kernel-library/linking-in-detail/linking-with-threading-libraries.html , but I am not sure if it only means that I cannot use open MP in my application or if it also means that I cannot use any other threading model (i.e. Microsoft PPL/std::thread) in my application (with "any compiler" (MSVS2017) and MKL in parallel mode)

[Gennady_F_Intel]

Jens, if you could link this case against the sequential version of mkl, then the problem you reported here, will be dissapear. Did you try this option?

[Jens_E_]

I have not tried that exactly, but I have tried to comment out the calls to mkl (cblas_dgemm in particular) and then the problem disappears.

I do wish to keep using pardiso in parallel (another part of the same application), so want to use the parallel version of mkl.

Note that mkl and my own std::thread and concurrency:: code do not work on the same data structures.

However I am concerned that the threading models (open MP and the Microsoft one) somehow still conflict.

[Jens_E_]

@Gennady_F_Intel Note that I did try

mkl_set_num_threads(1);

in my application (still using the parallel version of mkl) but before any calls to mkl. This had no effect. I thought this would be equivalent to linking with the sequential version.

[Gennady_F_Intel]

Yes, setting mkl_set_num_threads(1) before the very first call mkl’s routine is equivalent to linking with sequential versions.

Check the avoiding conflicts in the multithreaded environment chapter from the MKL Developer Guide follow the link (https://software.intel.com/content/www/us/en/develop/documentation/mkl-linux-developer-guide/top/managing-performance-and-memory/improving-performance-with-threading/avoiding-conflicts-in-the-execution-environment.html). The table considers several cases where conflicts may arise. MKL has to work properly when will call linked against sequential mode.

[Jens_E_]

@Gennady_F_Intel thanks - this was useful. 

It says Linux on the top - can I assume equivalent guidelines also are applicable to Windows?

The top row in the table is applicable to my situation. Is the issue related to performance (or possible deadlocks) alone or should I also be concerned about getting invalid results from mkl in that case?

[Gennady_F_Intel · Accepted solution]

yes, it also is applicable to Windows.

and yes, the issue is related to the performance first of all.

[Gennady_F_Intel]

This issue has been resolved and we will no longer respond to this thread. If you require additional assistance from Intel, please start a new thread. Any further interaction in this thread will be considered community only.