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
_progressMeterCurrent
that 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;
localNPending
from 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