Parallel Inspector - OpenMP and MKL

[putner]

When using Parallel Inspector to find Threading errors I stumbled over following (presumably) false Data race detection.

I used Parallel Inspector to analyze an following Intel example:

// http://software.intel.com/en-us/articles/different-parallelization-techniques-and-intel-mkl-fft/

#include "stdio.h"
#include "mkl_types.h"
#include "mkl_dfti.h"
#include "omp.h"

int main(int argc, char**argv)
{
//float _Complex x[200][100];
MKL_Complex8 x[200][100];

MKL_LONG len[2];

//...put input data into x 0<=j<=199, 0<=k<=99

len[0] = 50; len[1] = 100;
// each thread calculates real FFT for matrix (50*100)

#pragma omp parallel
{
DFTI_DESCRIPTOR_HANDLE my_desc_handle;

MKL_LONG myStatus;

int myID = omp_get_thread_num ();
myStatus = DftiCreateDescriptor (&my_desc_handle, DFTI_SINGLE, DFTI_COMPLEX, 2, len);

myStatus = DftiCommitDescriptor (my_desc_handle);

myStatus = DftiComputeForward (my_desc_handle, &x [myID * len[0]] [0] );
myStatus = DftiFreeDescriptor (&my_desc_handle);

printf("myID == %d\\n", myID);

} /* End OpenMP parallel region */
}

The Analysis shows three Data race problems with my_desc_handle in these statements
1 myStatus = DftiComputeForward (my_desc_handle, &x [myID * len[0]] [0] );
2 myStatus = DftiCreateDescriptor (&my_desc_handle, DFTI_SINGLE, DFTI_COMPLEX, 2, len);
3 myStatus = DftiFreeDescriptor (&my_desc_handle);
The question is are the reported problems false positives or is there a problem with the (usage) of the mkl fft?

[roland-duerr]

Welcome putner!

I just tested your example with VTune 9.1.

The first conflict is:

Memory read at ... conflicts with a prior memory write at ...

Memory write: len[0] = 50; len[1] = 100;

Memory read: myStatus = DftiCreateDescriptor ( ... );

This is strange. I write some initial values in len. Then I read these values. What a terrible conflict!

This was only the first of 39 errors. Probably this is a false positive. I would like to know to find the real threading errors in this cloud of false positives.

[Jackson_M_Intel]

Hello,

The issue here is that MKLis usingstatically linked openMP. These are false positives because currently Inspector analyzes dynamically linked openMP and not statically linked openMP. One option is to use Inspector suppressions to ignore these false positives. You shouldn't see these false positives on code that uses dynamically linked openMP.

[Gennady_F_Intel]

Hello,

I tried to link this example dynamically : "mkl_intel_c_dll.libmkl_intel_thread_dll.libmkl_core_dll.liblibiomp5md.lib" but Inspector detected several data races.

--Gennady

[Gennady_F_Intel]

by the way, roland, I checked thisexampleand found that Inspector detected all Data-race issues on the lines 24,26, 28 and 29. There is some duplicating in the report but I have no ideawhere you saw so many error:

This was only the first of 39 errors.!!!

--Gennady

[Jackson_M_Intel]

With respect to trying to link dynamically: "mkl_intel_c_dll.libmkl_intel_thread_dll.libmkl_core_dll.liblibiomp5md.lib"

The data races are not due to the fact thatMKL is linked statically to your application, but the fact that MKL is statically linked to openMP internally. Regardless of the libraries you link in at runtime, the MKL libraries will still use statically linked openMP, which they were linked to when they were created.

Does this make sense? Even with the dynamic linking you performed the reported races are expected.

Thanks.