[lttng-dev] [PATCH 00/11] Add support for TSAN to liburcu
Dmitry Vyukov
dvyukov at google.com
Wed May 24 04:14:51 EDT 2023
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.
More information about the lttng-dev
mailing list