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
