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. However, ... > > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 > > index 89e7f5f5f45..e2700b05ec3 100644 > > --- a/libstdc++-v3/acinclude.m4 > > +++ b/libstdc++-v3/acinclude.m4 > > @@ -4284,7 +4284,7 @@ AC_DEFUN([GLIBCXX_CHECK_PTHREAD_COND_CLOCKWAIT], [ > > [glibcxx_cv_PTHREAD_COND_CLOCKWAIT=no]) > > ]) > > if test $glibcxx_cv_PTHREAD_COND_CLOCKWAIT = yes; then > > - AC_DEFINE(_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT, 1, [Define if > > pthread_cond_clockwait is available in <pthread.h>.]) > > + AC_DEFINE(_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT, (_GLIBCXX_TSAN==0), > > [Define if pthread_cond_clockwait is available in <pthread.h>.]) > > fi TSan does appear to have an interceptor for pthread_cond_clockwait, even if it lacks the others. Does this mean that this part is unnecessary? See: https://github.com/google/sanitizers/issues/1259 Thanks. Mike.
