We clearly see were are the conflicting load and store as well as where the concerned threads have been created. And all that in a digest manner.
It is a little bit more messy with strings (4 errors), but we have the information.
You also have the concerned symbol "_Z1xB5cxx11".
I don't know why helgrind does not demangle it. But you could do it with c++filt
.
And here we have our variable name: x[abi:cxx11]
...
Helgrind shows us the 3 data races, with duplicate, but it is clear.
Data race with notification flag:
Data race with first part of the string:
Data race with second part of the string:
With a lot of errors Helgrind points the race, we can watch only the first error:
With the little help of grep we see all the data race:
grep -E "(data_race|conflicts|data race)"
This is not really the job of helgrind to detect this, memcheck or other memory check can detect this error.
Again as said above this is note the job of helgrind.
Again as said above this is note the job of helgrind.
Helgrind does not detect the ABA problem exposed in this code.
Even after looping 1000 times multiple times.
Even with synchronization Helgrind does not detect the problem on Gcc.
However with clang + libc++ Helgrind does detect a problem:
Helgrind detect a data race on payload
this is good.
However if we put annotations this hide the error. We must take care of using them correctly.
Also atomic access must be suppressed.
Same as before helgrind can detect the error if we use annotations correctly.
Same as before helgrind can detect the error if we use annotations correctly.
Helgrind on gcc report error on atomics and again we can suppress these, clang does not.
Helgrind on gcc report error on atomics and again we can suppress these, clang this time also report errors.
As it was said before we must annotate the code to make helgrind understand the happens-before relations.
Helgrind does not detect anything.