data race false positives with parallel inspector and boost library

[Customer__Intel]

Hi all,
I am trying to get started with Parallel Inspector and am unsure how to proceed in the following scenario:

I ran Parallel Inspector on a rather large application of ours. We are using boost::threads and smart pointers and boost::asio and generally use a lot of multithreading.

I am getting a lot of data race errors from inside the boost libraries. From what I have seen so far, these involve interlocked operations and so I guess they are actually false positives and should be okay. There is this one for example, a read-write data race inside the boost::basic_timed_mutex functions.

read -

31 inline void* interlocked_read_acquire(void* volatile* x)
32 {
*33** void* const res=*x;

34 _ReadWriteBarrier();
35 return res;
36 }

where x points to 'event' (see below)

write -
152 void* const old_event=BOOST_INTERLOCKED_COMPARE_EXCHANGE_POINTER(&event,new_event,0);

It looks as if basic_timed_mutex uses interlocked_increments for a fast mutex mechanism and only uses actual win32 semaphores if the interlocked counter indicates concurrency.

What strategy would you recommend for dealing with these potentially false positives? My problem is, there are so many data race errors, 10 alone when I start and close the application without any actual work.

I would like to get to the point where I can actually analyse my own code. I don't have the time to understand and analyse all instances of possible data races in the boost library. OTOH, if I simply suppress all these errors, won't I possibly miss a real error caused by my own code, that manifests itself in a data race in the boost libraries?

Any thoughts?

Also I'd like to understand the Parallel Inspector mechanism a bit more so I can have more confidence in what is going on under the hood. Is there a white-paper, in-depth-faq or something that explains this more?

Best regards and thank you

Hajo Kirchhoff

[Peter_W_Intel]

Hi,

Thank youto raisethis problem- I suppose that BOOST is not formally supported.Intel Parallel Inspector supports atomic, semaphore, mutex, critical-sectionfrom WinThreads, pthreads, OpenMP*, Intel TBB.Intel Parallel Inspector will trace memory access with these APIs.

So the key point iswhether mutex from BOOST librarywas implemented by Win32 interlocks or semaphore? If Yes, Intel Parallel Inspector will report right data race.

Sometime, if one memory access is atomic, but other is not atomic - Parallel Inspector will report data race. See this article

Regards, Peter

[Customer__Intel]

Hi,
thanks for the pointer. I can see that this is indeed what is going on in that boost snippet. One memory thread is atomic (BOOST_INTERLOCKED...), the other is not.

I would like to see the boost library supported by parallel inspector. boost is, imho, one of the most influential and most important C++ libraries besides STL. Many elements of the forthcoming Cx0++ standard originated in boost and these parts are already included in the TR1. They include shared_ptr<> which triggers a parallel inspector data race.

Is there any chance parallel inspector will support boost in the future?

Also I am still looking for more information about how parallel inspector works. Not a short, entry level explanation, but indepth technical info that get right down to the binary instruction details. CPU-magic incantations, so to speak. It would help me understand better why parallel inspector warns me about something and would increase my confidence when choosing 'suppress'.

Thank you

Hajo

[Peter_W_Intel · Accepted solution]

Hi Hajo,

I have escalated this feature request (support boost library) to development team.

Thanks for your inputs.

Regards, Peter