data races with -fsanitize=thread
There are a lot of data races in Gmsh that one can easily detect by compiling it with Clang and running it with an OpenMP library compiled with
-DLIBOMP_TSAN_SUPPORT=1. See here for details.
Example of data races:
- global variables like
_progressMeterCurrentthat are read and overwritten by different threads in GmshMessage.cpp
- in Generator.cpp, the code uses a critical section to increment
nPending, but the value is read from un-atomically. The typical way to solve this:
int localNPending; #pragma omp atomic capture // or `#pragma omp critical` depending on what is available in MSVC localNPending = ++nPending;
localNPendingfrom that point on.
- in MeshGRegionHxt.cpp, from line 269 to line 278, a missing point can be create simultaneously by multiple threads.
Many are not critical issues, like the second one which will only show slightly incorrect progress information once in a while. However, some are serious bugs, like the third one. I would advise to try to fix all possible data races, even if they are unimportant and fixing them could result in slight performance drops. By having a data race free program, it is far simpler to detect new data races that are introduced during development.
I will take care of fixing MeshGRegionHxt.cpp
PS: I'm also making some changes in Hxt, which is why I was using the ThreadSanitizer in the first place