A little bit related question/problem - some of our system test jobs got significantly slower (3x-5x) with **clang-16** TSAN after we integrated liburcu to BIND 9. The GCC (13.1.1) TSAN doesn’t exhibit this behavior.
The liburcu integration in BIND 9 is very light at the moment - we use liburcu for qptrie and there’s some usage of wfcqueue for queuing jobs(callbacks) between threads. We were not able to put a finger on it yet, but saying this aloud might help diagnose this. Ondrej -- Ondřej Surý <ond...@sury.org> (He/Him) > On 24. 5. 2023, at 10:15, Dmitry Vyukov via lttng-dev > <lttng-dev@lists.lttng.org> wrote: > > On Tue, 23 May 2023 at 18:05, Olivier Dion <od...@efficios.com> wrote: >> >> Hi Dmitry, >> >> We do have a new issue and we think it might be a limitation from TSAN. >> >> Find attached a test program that we believe is correct. You can >> compile it with `gcc -fsanitize=thread test.c -pthread'. >> >> >> TSAN flags a race condition between the atomic store relaxed at line 36 >> and the free at line 81. >> >> We can solve the issue by replacing the atomic store relaxed with a >> atomic store release. However, the preceding atomic exchange with >> sequential consistency already acts as an implicit release (in term of >> memory barrier) for the following store, making the release semantic >> redundant. >> >> We've found an alternative to fix this by ignoring the thread during the >> relaxed store (line 39). However, what we would like is to annotate the >> memory stored (line 45). >> >> My theory (I don't know the internal of TSAN much) is that TSAN thinks >> for some reason that the atomic store relaxed happen at the same epoch >> as the free, resulting in a false positive. If so, m > > > I don't this this is true in the C/C++ memory model: > "the preceding atomic exchange with sequential consistency already > acts as an implicit release (in term of memory barrier) for the > following store". > > std::atomic_thread_fence does affect all preceding/subsequent > operations, but an atomic memory operation only affects ordering on > that variable, it doesn't also serve as a standalone memory fence. > _______________________________________________ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
