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

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ý <[email protected]> (He/Him)

> On 24. 5. 2023, at 10:15, Dmitry Vyukov via lttng-dev <[email protected]> wrote:
> 
> On Tue, 23 May 2023 at 18:05, Olivier Dion <[email protected]> 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
> [email protected]
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

_______________________________________________
lttng-dev mailing list
[email protected]
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev