3 ms·

I don't have a photo but we used to have the same sign at Google, with an added note "unless accompanied by ThreadSanitizer". At runtime: https://clang.llvm.or

I don't have a photo but we used to have the same sign at Google, with an added note "unless accompanied by ThreadSanitizer". At runtime: https://clang.llvm.org/docs/ThreadSanitizer.html https://clang.llvm.org/docs/ThreadSanitizer.html At compile-time: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html https://clang.llvm.org/docs/ThreadSafetyAnalysis.html The article points out that that: The resulting invariants end up being documented in comments: // These variables are protected by monitor X: but you can write those in C++ code and have the compiler check them. That's what thread safety annotations are for.

kubanczyk 4y ago
TIL that, so predictably, "[Go's] race detector is based on the C/C++ ThreadSanitizer runtime library". So, I can definitely confirm its usefulness. https://go.dev/blog/race-detector https://go.dev/blog/race-detector
GuB-42 4y ago
I use Valgrind's helgrind. In fact, Valgrind is generally my favorite debugging tool: memcheck (default) for memory errors and leaks, callgrind for profiling, massif for memory profiling and finding "stealth" leaks, helgrind for multi-threading and a few others that I use less often. The great thing about Valgrind is that it doesn't require any instrumentation at build time (though debug symbols are recommended), just run "valgrind your_program". Behind the scenes, it is actually a VM, that's how it can work with binaries directly. In theory it works with any language, and no need to do anything funny with libraries, kernel stuff, etc... The biggest problem is that the performance penalty is huge, 10x is typical but 100x is not uncommon. ThreadSanitizer is slow but not that slow, I don't know which one is the best at finding issues, I think they are on par, but when you are an a particularly hairy problem, it is good to have both.
- wallstprog 4y ago
  valgrind is great, but be aware that valgrind runs single-threaded, which definitely changes the way multi-threaded apps behave: https://valgrind.org/docs/manual/manual-core.html#manual-core.pthreads_perf_sched https://valgrind.org/docs/manual/manual-core.html#manual-cor... In practice what this means is that cpu-bound threads can monopolize the single thread, and we've had thread starvation issues as a result in some tests. Setting the "-fair-sched" option resolved those issues, but made valgrind run even slower ...

kubanczyk 4y ago

TIL that, so predictably, "[Go's] race detector is based on the C/C++ ThreadSanitizer runtime library". So, I can definitely confirm its usefulness. https://go.dev/blog/race-detector https://go.dev/blog/race-detector

GuB-42 4y ago

I use Valgrind's helgrind. In fact, Valgrind is generally my favorite debugging tool: memcheck (default) for memory errors and leaks, callgrind for profiling, massif for memory profiling and finding "stealth" leaks, helgrind for multi-threading and a few others that I use less often. The great thing about Valgrind is that it doesn't require any instrumentation at build time (though debug symbols are recommended), just run "valgrind your_program". Behind the scenes, it is actually a VM, that's how it can work with binaries directly. In theory it works with any language, and no need to do anything funny with libraries, kernel stuff, etc... The biggest problem is that the performance penalty is huge, 10x is typical but 100x is not uncommon. ThreadSanitizer is slow but not that slow, I don't know which one is the best at finding issues, I think they are on par, but when you are an a particularly hairy problem, it is good to have both.

wallstprog 4y ago
valgrind is great, but be aware that valgrind runs single-threaded, which definitely changes the way multi-threaded apps behave: https://valgrind.org/docs/manual/manual-core.html#manual-core.pthreads_perf_sched https://valgrind.org/docs/manual/manual-core.html#manual-cor... In practice what this means is that cpu-bound threads can monopolize the single thread, and we've had thread starvation issues as a result in some tests. Setting the "-fair-sched" option resolved those issues, but made valgrind run even slower ...