False data race with tbb::mutex::scoped_lock shown by Parallel Inspector

[Andrei_Vermel]

Reposting from the TBB forum, since I got no reply there.

In a block of code guarded by a tbb::mutex::scoped_lock Parallel Inspector shows a data race.
With a spin_mutex the error message goes away.
This is in both in a debug and a release build with TBB_USE_THREADING_TOOLS=1.

Looks like Parallel Inspector is kept silent with ITT_NOTIFY, but for some reason isn't with EnterCriticalSection.

Any hints what to do about it?

[ARCH_R_Intel]

Do you have a small example that you could send? I tried to reproduce the problem with the code below, and Parallel Inspector showed no races when I linked it against the debug version of TBB. When I removed the line that constructs "lock", then Parallel Inspector showed a race as expected.

[cpp]#include "tbb/mutex.h"
#include "tbb/parallel_for.h"
#include "tbb/blocked_range.h"
#include 

tbb::mutex global_mutex;
int global_data;

struct Functor {
    void operator()( tbb::blocked_range r ) const {
        for( int i=r.begin(); i!=r.end(); ++i ) {
            tbb::mutex::scoped_lock lock(global_mutex);
            ++global_data;
        }
    }
};

int main() {
    tbb::parallel_for( tbb::blocked_range(0,1000000), Functor() );
    std::printf("%dn",global_data);
    return 0;
}[/cpp]

[Andrei_Vermel]

Quoting - Arch Robison (Intel)

Do you have a small example that you could send? I tried to reproduce the problem with the code below, and Parallel Inspector showed no races when I linked it against the debug version of TBB. When I removed the line that constructs "lock", then Parallel Inspector showed a race as expected.

Thank you for taking a look at it.
Yes, your code in essence is the same that I've got.
So far I am unable to reproduce it on a small example. Sorry, I really should have tried before posting.
The mutex lock is down a long function call chain, so this might possibly be the reason.
I can't reproduce it with multiple stub functions though.