|
@Jonathan_Blow | |||||
|
It reminds me a little bit of Warning Cleanup Theatre from the 1990s and 2000s (and probably today), where people insert a bunch of casts into their code and now there are no more warnings, so The Code Must Be Better Now With All These Casts. Except data races are more serious.
|
||||||
|
||||||
|
Jonathan Blow
@Jonathan_Blow
|
2. velj |
|
So I am using ThreadSanitizer, and I find myself cleaning up data races that don't matter, in order to keep the output clean. (For example, an atomic set of a flag, where another thread reads that flag word, but doesn't care about that flag). On the one hand,
|
||
|
|
||
|
Jonathan Blow
@Jonathan_Blow
|
2. velj |
|
this means the diagnostics will be clean from spurious data races, which helps us spot real races. But on the other hand, it can have negative performance impacts on the code, for example by increasing memory use as I introduce more flag words.
|
||
|
|
||
|
Jonathan Blow
@Jonathan_Blow
|
2. velj |
|
So I am doing it, but, it doesn't feel totally good to me.
P.S. What is the best practice for getting tsan to shut up if there is an actual data race that you intend to be there and is fine (e.g. a thread polls a location to see if a value shows up there), without
|
||
|
|
||
|
Jonathan Blow
@Jonathan_Blow
|
2. velj |
|
doing something that might cause you to miss a real problem later?
|
||
|
|
||
|
Michael Spencer
@Bigcheesegs
|
21 h |
|
Major difference with the sanitizers is that they have a near zero percent false positive rate by design. TSan is giving you reports based on the compiler's view of the world and what assumptions it makes. It doesn't care what CPU you're targeting, as it doesn't matter.
|
||
|
|
||
|
Jonathan Blow
@Jonathan_Blow
|
20 h |
|
Nope. This is the whole problem with this mindset. It *does* matter, because the actual job I am trying to do is put a specific program onto a specific computer.
It's not that toxic in this case, but the whole UB cluster-f is super toxic.
|
||
|
|
||