[lttng-dev] [PATCH 00/11] Add support for TSAN to liburcu

[Dmitry Vyukov]

On Fri, 26 May 2023 at 07:33, Ondřej Surý <ondrej at sury.org> wrote:
>
> 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.

Interesting. Clang 16 got a completely new tsan runtime
implementation, which is generally ~2x faster and consumes less
memory.
However, of course, it's not possible to optimize for all gazillion of
programs in the world. I suspect librcu tests are quite extreme in
terms of synchronization.

If you collect perf profiles for both, I can look for some low hanging fruit.
Or is there a reasonable way for me to reproduce?


> Ondrej
> --
> Ondřej Surý <ondrej at sury.org> (He/Him)
>
> > On 24. 5. 2023, at 10:15, Dmitry Vyukov via lttng-dev <lttng-dev at lists.lttng.org> wrote:
> >
> > On Tue, 23 May 2023 at 18:05, Olivier Dion <odion at 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 at lists.lttng.org
> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>