On Thu, 11 May 2023 at 16:54, Thomas Rodgers <trodg...@redhat.com> wrote:
> > > On Thu, May 11, 2023 at 5:21 AM Mike Crowe via Libstdc++ < > libstd...@gcc.gnu.org> wrote: > >> On Wednesday 10 May 2023 at 12:31:12 +0100, Jonathan Wakely wrote: >> > On Wed, 10 May 2023 at 12:20, Jonathan Wakely via Libstdc++ < >> > libstd...@gcc.gnu.org> wrote: >> > >> > > This patch would avoid TSan false positives when using timed waiting >> > > functions on mutexes and condvars, but as noted below, it changes the >> > > semantics. >> > > >> > > I'm not sure whether we want this workaround in place until tsan gets >> > > fixed. >> > > >> > > On one hand, there's no guarantee that those functions use the right >> > > clock anyway (and they won't do unless a recent-ish glibc is used). >> But >> > > on the other hand, if they normally would use the right clock because >> > > you have glibc support, it's not ideal for tsan to cause a different >> > > clock to be used. >> > > >> > >> > But of course, it's not ideal to get false positives from tsan either >> > (especially when it looks like a libstdc++ bug, as initially reported to >> > me). >> >> I think that this is probably the least-worst option in the short term. As >> TSan is distributed with GCC this workaround can be removed as soon as its >> TSan implementation gains the necessary interceptors. I shall look into >> trying to do that. >> >> > I don't have a strong opinion either way on this, but I think documenting > the TSAN suppressions is the option most in keeping with the principle of > Least Astonishment. > That assumes anybody reads the docs :-) Getting TSan errors from the std::lib is somewhat astonishing. The errors could be avoided, at the risk of subtle timing differences between tsanitized and un-tsanitized builds ... but won't there be subtle diffs anyway based on the TSan overhead? Admittedly those will just be fairly constant overhead, and so immune to system clock adjustments.
