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. > 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. > >
