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.
31 inline void* interlocked_read_acquire(void* volatile* x)
*33** void* const res=*x;
35 return res;
where x points to 'event' (see below)
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?
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