- TSA is a static analyzer build by Google which finds race conditions
and deadlocks at compile time.
- It works by associating a shared member variable with a
synchronization primitive that protects it. The compiler can then
check at each access if proper locking happened before. A good
introduction are [0] and [1].
- TSA requires some help by the programmer via annotations. Luckily,
LLVM's libcxx already has annotations for std::mutex, std::lock_guard,
std::shared_mutex and std::scoped_lock. This commit enables them
(--> contrib/libcxx-cmake/CMakeLists.txt).
- Further, this commit adds convenience macros for the low-level
annotations for use in ClickHouse (--> base/defines.h). For
demonstration, they are leveraged in a few places.
- As we compile with "-Wall -Wextra -Weverything", the required compiler
flag "-Wthread-safety-analysis" was already enabled. Negative checks
are an experimental feature of TSA and disabled
(--> cmake/warnings.cmake). Compile times did not increase noticeably.
- TSA is used in a few places with simple locking. I tried TSA also
where locking is more complex. The problem was usually that it is
unclear which data is protected by which lock :-(. But there was
definitely some weird code where locking looked broken. So there is
some potential to find bugs.
*** Limitations of TSA besides the ones listed in [1]:
- The programmer needs to know which lock protects which piece of shared
data. This is not always easy for large classes.
- Two synchronization primitives used in ClickHouse are not annotated in
libcxx:
(1) std::unique_lock: A releaseable lock handle often together with
std::condition_variable, e.g. in solve producer-consumer problems.
(2) std::recursive_mutex: A re-entrant mutex variant. Its usage can be
considered a design flaw + typically it is slower than a standard
mutex. In this commit, one std::recursive_mutex was converted to
std::mutex and annotated with TSA.
- For free-standing functions (e.g. helper functions) which are passed
shared data members, it can be tricky to specify the associated lock.
This is because the annotations use the normal C++ rules for symbol
resolution.
[0] https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
[1] https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42958.pdf
WEVERYTHING enables on Clang literally every warning. People on the
internet are divided if this is a good thing or not but ClickHouse
compiles with -Weverything + some exceptions for noisy warnings since at
least a year.
I tried to build with WEVERYTHING = OFF and the build was badly broken.
It seems nobody actually turns WEVERYTHING off. Actually, why would one
if the CI builds (configured with WEVERYTHING = ON) potentially generate
errors not generated in local development.
To simplify the build scripts and to remove the need to maintain two
sets of compiler warnings, I made WEVERYTHING the default and threw
WEVERYTHING = OFF out.
Since libstdc++ has some of such compares for 3way compare:
/src/ch/clickhouse/src/Common/UInt128.h:61:71: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]
bool inline operator>= (const UInt128 rhs) const { return tuple() >= rhs.tuple(); }
^~
nullptr
/usr/include/c++/10.2.0/tuple:1426:5: note: while rewriting comparison as call to 'operator<=>' declared here
operator<=>(const tuple<_Tps...>& __t, const tuple<_Ups...>& __u)
clang (10.0.0 is fine BTW) will warn about this anyway on CI.
For the debug build gcc10:
- before patch:
- concat.cpp -> >5m (stuck on cc1plus, not as)
- has.cpp -> >10m (stuck on cc1plus, not as)
- after this patch:
- concat.cpp -> 1m16s
- has.cpp -> 4m (and most of the time eats, as from binutils 2.34.50.20200508)
Command for build:
- ninja src/Functions/GatherUtils/CMakeFiles/clickhouse_functions_gatherutils.dir/concat.cpp.o
- ninja src/Functions/GatherUtils/CMakeFiles/clickhouse_functions_gatherutils.dir/has.cpp.o
The test case should be reduced and then it can be reported to the gcc
bugzilla.
P.S. Looks like a signal not to switch to gcc10 for now
