Confirm multi-threaded compatibility

[yevs19]

Hi,

We are building a custom MKL 10.0.012 DLL for IA32, to be called by our C# .NET 2005 application via PInvoke.

We are using the builder tool, with stdcall and a def file.

Our application uses Windows Forms and is multi-threaded (we call VML functions from multiple threads).

I found the documentation a bit confusing here; I got the impression that if the builder tool linked mkl_intel_thread.lib and libiomp5md.lib, then we would be able to use the resulting multi-threaded custom DLL with our .NET application. Unfortunately, when we run the application on a multi-core machine, the software crashes without many diagnostics when the custom MKL DLL is invoked.

We are able to build and run successfully by just linking mkl_sequential.lib - but I wanted to clarify whether we would be able to use the multi-threaded layer.

Thanks and regards.

[TimP]

If your upper level threading doesn't use OpenMP, I can see the MKL threading having difficulty tracking the number of threads. If there were trouble caused by each .dll attempting to initialize OpenMP, you should get the warning about multiple initializations, which means you are in unsupported territory. I doubt that your scenario is well tested. If you know how many threads you want used by MKL, you should set that number in OMP_NUM_THREADS environment variable.

[Andrey_G_Intel2]

could you try to use libguide40.lib instead libiomp5md.lib?

[yevs19]

Setting OMP_NUM_THREADS to 1 allows the application to run without errors (albeit with the same performance characteristics as mkl_sequential?)

Setting OMP_NUM_THREADS to 2+ causes the application to fail as before.

[yevs19]

Unfortunately, using libguide40 didn't seem to make any difference here.

[Todd_R_Intel]

There was a DLL builder bug fixed in update 3 which is available now. I'm afraid I can't promise it will address your issue based on the info on this thread, but I mention it in case you're up for the experiment.
-Tod

[Intel_C_Intel]

I tried again with Update 3 but still having access violations whenever I call anything from VML. Can I find out specifically what memory issue the update addressed?