TSAN: warn about usage of atomic_thread_fence #1352
Comments
|
Good question. I agree that the current failure mode is very suboptimal as it's hard to map the false reports back to tsan's mishandling on atomic_thread_fence. |
|
All right, I'm planning to introduce a new warning for the GCC compiler. |
|
How do other projects deal with such missing support? Do they filter out all findings from a source file or library? I imagine it's hard to totally avoid using explicit barriers. |
|
FWIW all of Chromium and most of our internal code is tested as is. This only affects acquire/release fences, and these are rarely needed (only some implementations of seqlock optimized for non-TSO arches come to mind). Some __tsan_acquire/release annotations can help to deal with this as well. |
|
Unfortunately our code base has quite a lot of explicit fences. Some certainly can be removed, but others are needed for better performance.
Can you elaborate on this please? I could not find any references to such annotations. |
Here they are: |
For example, google/sanitizers#1352 - tsan is not working well with std::atomic_thread_fence Minimal reproducible example (and one that bothers most in every fiber-aware service): ``` auto threadPool = NYT::New<NYT::NConcurrency::TThreadPool>(2, "thread"); TVector<NYT::TFuture<void>> futures; for (size_t i = 0; i < 100000; ++i) { futures.emplace_back(BIND([]() { }).AsyncVia(threadPool->GetInvoker()).Run()); } for (auto& future : futures) { future.Get().ThrowOnError(); } ```
For example, google/sanitizers#1352 - tsan is not working well with std::atomic_thread_fence Minimal reproducible example (and one that bothers most in every fiber-aware service): ``` auto threadPool = NYT::New(2, "thread"); TVector> futures; for (size_t i = 0; i GetInvoker()).Run()); } for (auto& future : futures) { future.Get().ThrowOnError(); } ``` ref:3e00460e50688a7605e91115ffb25a041f2061bf
For example, google/sanitizers#1352 - tsan is not working well with std::atomic_thread_fence Minimal reproducible example (and one that bothers most in every fiber-aware service): ``` auto threadPool = NYT::New(2, "thread"); TVector> futures; for (size_t i = 0; i GetInvoker()).Run()); } for (auto& future : futures) { future.Get().ThrowOnError(); } ``` ref:3e00460e50688a7605e91115ffb25a041f2061bf
As mentioned here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97868
It's quite a common case where people complain about TSAN that it doesn't support
atomic_thread_fence.Can we provide a warning (either compile-time or run-time) for it?
What do you think?
The text was updated successfully, but these errors were encountered: