Parallel Studio Inspect reports data race where there is none

[dipaktc]

Hello

I have a piece of code which I tried to parallelize using OpenMP. And then used parallel studio to check for data race. It reported one. But I cannot understand why this instance is reported as data race. Can some please help me understand this instance.

Below is the piece of code.

typedef int int32;
typedef char int8;

void**
Alloc ( int32 nRowNum, int32 nColumnNum, int32 sItemSize )
{
void** ppvBuffer = 0;
int8* pvBuffer = 0;
int32 lIndex;
int32 nStep = nColumnNum * sItemSize ;

if ( !nRowNum || !nColumnNum )
return NULL;

ppvBuffer = (void**)new void* [ nRowNum ];
memset(ppvBuffer, 0, sizeof(void*) * nRowNum);
pvBuffer = (int8*)new int8 [ nRowNum*nColumnNum*sItemSize ];
memset(pvBuffer, 0, sizeof(int8) * nRowNum*nColumnNum*sItemSize);
for ( lIndex = 0; lIndex < nRowNum; lIndex++, pvBuffer += nStep )
ppvBuffer[ lIndex ] = pvBuffer;

return ppvBuffer;
}

void
Free ( void** ppvBuffer)
{
if ( ppvBuffer )
{
if ( ppvBuffer[0] )
delete [] ppvBuffer[0];

delete [] ppvBuffer;
}
ppvBuffer = NULL;
}

void function1(int8 **ppBuffer)
{
int x, y;
#pragma omp parallel for private(x,y) shared(ppBuffer)
for(x = 0; x < 10; x++)
for(y = 0; y< 10; y++)
ppBuffer = 10;
return;
}


void function2(int8 **ppBuffer1, int8 **ppBuffer2)
{
int x, y, i, j;
#pragma omp parallel for private(x,y, i, j)shared(ppBuffer2, ppBuffer1)
for(x = 0; x < 10; x++)
{
i = x + 1;
for(y = 0; y< 10; y++)
{
j = y + 1;
ppBuffer2 = ppBuffer1;
}
}
return;
}

int main(void)
{
int8 ** ppBuffer1 = NULL;
int8 ** ppBuffer2 = NULL;

ppBuffer1 = (int8 **)Alloc(11, 11, sizeof(char));
ppBuffer2 = (int8 **)Alloc(11, 11, sizeof(char));

function1(ppBuffer1);
function2(ppBuffer1, ppBuffer2);

Free((void **)ppBuffer1);
Free((void **)ppBuffer2);

return 0;
}

I have used Visuall Studio 2005 Compiler. Intel parallel studio reports that there is a data race between read in function2 and a write in function 1.( which are highlighted).

Surprisingly, if I use the Intel C++ compiler, the data race is gone.

Also in the above implementation if I separate the pragma for "parallel" and "for" as shown below in both functions data race is gone.

#pragma omp parallel private(x,y) shared(ppBuffer)
{
#pragma omp for
for(x = 0; x < 10; x++)
for(y = 0; y< 10; y++)
ppBuffer = 10;
return;
}

Any help in this regard is highly appreciated.

Thanks in advance.

[Vladimir_T_Intel]

Hi,

I'd like to investigate it further, but looking at the code I'd rather consider the reported data race as false positive since the parallel region in function1 should join before creating parallel region in the function2. Let me try to reproduce it at my side with the latest product build. I'll update you with the results.

Thanks.

[dipaktcgmail_com]

Quoting - Vladimir Tsymbal (Intel)

Hi,

I'd like to investigate it further, but looking at the code I'd rather consider the reported data race as false positive since the parallel region in function1 should join before creating parallel region in the function2. Let me try to reproduce it at my side with the latest product build. I'll update you with the results.

Thanks.

Hi

Were you able to reproduce this problem ? Can you please update.

Thanks,
Deepak

[Vladimir_T_Intel]

Quoting - dipaktcgmail.com

Hi

Were you able to reproduce this problem ? Can you please update.

Thanks,
Deepak

Hi,

I'm so sorry, this case slipped my attention (probably, because we had some problems w/ forum notifications). Thanks for pinging me.

I checked your test case with all levels ti2-ti4 (Inspector v1.0 Update 1).

Intel Compiler v.11.1

Inspector detects a data race on ti2 level but within each function (function1 and fuction2). If selected higher levels (t3-t4), it recognizes that the accesses to the buffer are not overlapped and does not report errors.

MSFT Compiler 8.0

Quite the opposite results

Inspector doesn't detect data races on ti2

On ti3-ti4 it detects race condition in accessing buffer memory in fucnction1 and function2.

It quite strange and I can't say for sure who is the culprit here, MSFT omp or Inspector. I'll submit this issue to Inspector developers for further investigation.

I'll let you know the results.

Thanks.

[Vladimir_T_Intel]

Quoting - Vladimir Tsymbal (Intel)

MSFT Compiler 8.0

Quite the opposite results

Hi,

I just learned that Inspector doesn't support MSFT OpenMP run-time (shame on me).

Please see the Release Notes:

"Intel Parallel Inspector supports analysis of applications built with Intel Parallel Composer, Intel C++ Compiler Professional Edition version 10.0 or higher, and/or Microsoft Visual C++* 2005 or 2008. Applications that use OpenMP* and are built with the Microsoft* compiler must link to the OpenMP* compatibility library as supplied by an Intel compiler."

In order to workaround this limitation you should link with the Intel OpenMP compatibility library. You need to avoid linking the Microsoft OpenMP run-time library (vcomp) and explicitly pass the name of the Intel OpenMP compatibility library as linker options.

In the Visual Studio IDE:

Project Properties -> Linker -> Input -> Ignore Specific Library -> put vcomp.dll or vcompd.dll here

Project Properties -> Linker -> Input -> Additional Dependencies -> put libiomp5md.lib here

In the command line:

icl /MD /openmp hello.cpp /link /NODEFAULTLIB:"vcomp.dll" libiomp5md.lib

For more information refer to Using the OpenMP Compatibility Libraries document