I have an openMP code that takes 8 instances of a class and uses them in parallel (the class itself is a well known particle physics simulation code). It runs slower on multiple cores than on a single core however.
When using Intel Inspector, I find data races in various functions of the class that seem to be related to basic maths functions in libm. See this screenshot for an example involving atan:
Is this genuine or a false positive? In which case, do I need to find an alternate thread safe implementation of these functions? I have checked the class itself and there are no static or global variables, so the objects themselves should be private in the omp parallel block.
A simple version of my code is this (the init function calls lots of other functions that heavily use the maths functions)
#pragma omp parallel
Did you use Inspector 2016 version to find these data race? There are some problems fixed in latest version.
I feel strange that functions (asin, acos, atan) might use local variables, they should have no global (shared) variable to cause data race when used by multiple threads. I cannot see your screen-shot, why you didn't attach picture on this thread? It's better to send me small test case to run this on my side. Thank you.
I had to shrink the image, but it now is embedded ok. I repeated my test in the 2016 version of Inspector and I still see the data races (the screenshot below is from the earlier version however).
Unfortunately, it is rather hard to make a small example. It requires building and running the entire Pythia program. This is not too difficult, but you might consider it beyond the call of duty.
I can send a tarball with instructions if you are willing?
Thanks for your tarbar file, after I extracted this then do:
3) go to examples, and "make main24"
4) inspxe-cl -c ti3 -- ./main24
I found Read/Write data race (P3) in line #263 of ParticleData.cc, which called atan() in different thread. "double m0Save, mWidthSave, mMinSave, mMaxSave..." are defined include file. It seemed there was only read of these data, why was there read/write data race.
I will escalate this issue to developer and get back to your soon.
Thanks Peter. That is indeed what I see (and there are similar errors through the code, usually related to libm functions).
What puzzles me is that the variables (m0Save, etc) should be private member variables of the Pythia class, and hence there should be no overlap between the threads.