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

[Dmitry Vyukov via lttng-dev <lttng-dev@lists.lttng.org>]

On Tue, 23 May 2023 at 18:05, Olivier Dion <odion@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