aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-cov/CodeCoverage.cpp
diff options
context:
space:
mode:
authorLogikable <seanluchen@google.com>2024-06-13 10:03:15 -0700
committerGitHub <noreply@github.com>2024-06-13 10:03:15 -0700
commit6499c5d70c2514ff0997bac3b442bd0381591d77 (patch)
tree320c6e6792e45bcb53e625695dfe644cfd8d7ac8 /llvm/tools/llvm-cov/CodeCoverage.cpp
parenta2393435217a0c8832b6b34e13977bb29d722d39 (diff)
downloadllvm-6499c5d70c2514ff0997bac3b442bd0381591d77.zip
llvm-6499c5d70c2514ff0997bac3b442bd0381591d77.tar.gz
llvm-6499c5d70c2514ff0997bac3b442bd0381591d77.tar.bz2
[compiler-rt][builtins] Add opt-in pthread_mutex_t locks to libatomic (#95326)
When an uninstrumented libatomic is used with a TSan instrumented memcpy, TSan may report a data race in circumstances where writes are arguably safe. This occurs because __atomic_compare_exchange won't be instrumented in an uninstrumented libatomic, so TSan doesn't know that the subsequent memcpy is race-free. On the other hand, pthread_mutex_(un)lock will be intercepted by TSan, meaning an uninstrumented libatomic will not report this false-positive. pthread_mutexes also may try a number of different strategies to acquire the lock, which may bound the amount of time a thread has to wait for a lock during contention. While pthread_mutex_lock has a larger overhead (due to the function call and some dispatching), a dispatch to libatomic already predicates a lack of performance guarantees.
Diffstat (limited to 'llvm/tools/llvm-cov/CodeCoverage.cpp')
0 files changed, 0 insertions, 0 deletions