diff options
| author | Logikable <seanluchen@google.com> | 2024-06-13 10:03:15 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-06-13 10:03:15 -0700 |
| commit | 6499c5d70c2514ff0997bac3b442bd0381591d77 (patch) | |
| tree | 320c6e6792e45bcb53e625695dfe644cfd8d7ac8 /llvm/tools/llvm-cov/CodeCoverage.cpp | |
| parent | a2393435217a0c8832b6b34e13977bb29d722d39 (diff) | |
| download | llvm-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
