From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 5793C3858C78 for ; Wed, 10 May 2023 11:31:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5793C3858C78 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683718287; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dyaWSCtlJCI/qa5JM2eVzyPqU5JOmZddksDEKDcIy0w=; b=Bze4ce5KfyH3dOv/1aMitJ1UsQdTUjhJpXMH3tGttHwqqKrx55Ubyc/X2oVtVpTOpWARAF 79Xl3uQOwCmzIhKn0lHxdfQIifLjOE2DpSf+TMl7g3goWVu4hi+5eVjbQ1gRl00MZfWx6f WRurGIdPT1OTMQpG7bhQNitYUS9BamU= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-147-wBC-eizdOdiYX3TrsLpy5A-1; Wed, 10 May 2023 07:31:25 -0400 X-MC-Unique: wBC-eizdOdiYX3TrsLpy5A-1 Received: by mail-lj1-f199.google.com with SMTP id 38308e7fff4ca-2ac7cefaa9dso36134091fa.2 for ; Wed, 10 May 2023 04:31:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683718284; x=1686310284; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dyaWSCtlJCI/qa5JM2eVzyPqU5JOmZddksDEKDcIy0w=; b=VTST/CF1EHgOoRjd8pueR79exQR5QOgAZJvtOw+/jIiv50q8ckui/6g8khzaA7nFfS trep36K2ppCOW8hUWGoSyPaKObFBMx8aAaUSERH8/UmQMnNgu5yJbFVsAh5Htb2uCooc SoB+DI99Y6IAVfI8hRMBB0NsMGVe9pZ9BEnTtgxuNPM8nSZ/7Nh6MgxriBHWPqqg1PdZ e+b+EtJ1aMAF5XYp0HfxeQajbuWTvcaWYUF2BHtlhztMDhwuRGqFnO4pTU+eymHfnA82 DbAJFwL06v+eqnZC19BZG32pAroaPoE6AYs9qgDVMu3D+3cCJTbFwCrw/gS8MaRh761G uMwA== X-Gm-Message-State: AC+VfDyYMfo5homq7J1XYrMD2RwgVhpf8SUbX34JnowLt3z6QbpSxsoW jaBM1r4xSKHIQGltjNi55MOEoTb1mcZPAGKQE874yD8ThZJdST3Kd8S2nh1ODOWgD9Wjc7vEEEH B+L7oEKPySZVmas1nntHOBjmmeIOLEMgmhg== X-Received: by 2002:a2e:b172:0:b0:2a7:8150:82c1 with SMTP id a18-20020a2eb172000000b002a7815082c1mr1856282ljm.38.1683718283794; Wed, 10 May 2023 04:31:23 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7U97Zkj+D0zpCTat15jyxRP/Upsgm8Qpnrrt38JyFyfqs9Dreiq38pUnvkypZY7D1pq+w+drdWyrl8lkuHtz8= X-Received: by 2002:a2e:b172:0:b0:2a7:8150:82c1 with SMTP id a18-20020a2eb172000000b002a7815082c1mr1856275ljm.38.1683718283422; Wed, 10 May 2023 04:31:23 -0700 (PDT) MIME-Version: 1.0 References: <20230510112009.633444-1-jwakely@redhat.com> In-Reply-To: <20230510112009.633444-1-jwakely@redhat.com> From: Jonathan Wakely Date: Wed, 10 May 2023 12:31:12 +0100 Message-ID: Subject: Re: [RFC] libstdc++: Do not use pthread_mutex_clocklock with ThreadSanitizer To: Jonathan Wakely Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Mike Crowe X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000002f80cb05fb5536c4" X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000002f80cb05fb5536c4 Content-Type: text/plain; charset="UTF-8" On Wed, 10 May 2023 at 12:20, Jonathan Wakely via Libstdc++ < libstdc++@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). > > -- >8 -- > > As noted in https://github.com/llvm/llvm-project/issues/62623 there are > no tsan interceptors for the new POSIX-1:202x APIs added by > https://austingroupbugs.net/view.php?id=1216 so tsan gives false > positive warnings. > > Disable the uses of the new APIs when tsan is active. This changes the > semantics of those functions, because it can change which clock is used > for the wait. This means those functions might be affected by system > clock adjustments when tsan is used, when they would not be affected > otherwise. > > libstdc++-v3/ChangeLog: > > * acinclude.m4 (GLIBCXX_CHECK_PTHREAD_COND_CLOCKWAIT): Define > _GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT to depend on _GLIBCXX_TSAN. > (GLIBCXX_CHECK_PTHREAD_MUTEX_CLOCKLOCK): Likewise for > _GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK. > (GLIBCXX_CHECK_PTHREAD_RWLOCK_CLOCKLOCK): Likewise for > _GLIBCXX_USE_PTHREAD_RWLOCK_CLOCKLOCK. > * configure: Regenerate. > --- > libstdc++-v3/acinclude.m4 | 6 +++--- > libstdc++-v3/configure | 6 +++--- > 2 files changed, 6 insertions(+), 6 deletions(-) > > 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 .]) > + AC_DEFINE(_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT, (_GLIBCXX_TSAN==0), > [Define if pthread_cond_clockwait is available in .]) > fi > > CXXFLAGS="$ac_save_CXXFLAGS" > @@ -4314,7 +4314,7 @@ AC_DEFUN([GLIBCXX_CHECK_PTHREAD_MUTEX_CLOCKLOCK], [ > [glibcxx_cv_PTHREAD_MUTEX_CLOCKLOCK=no]) > ]) > if test $glibcxx_cv_PTHREAD_MUTEX_CLOCKLOCK = yes; then > - AC_DEFINE(_GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK, 1, [Define if > pthread_mutex_clocklock is available in .]) > + AC_DEFINE(_GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK, (_GLIBCXX_TSAN==0), > [Define if pthread_mutex_clocklock is available in .]) > fi > > CXXFLAGS="$ac_save_CXXFLAGS" > @@ -4346,7 +4346,7 @@ AC_DEFUN([GLIBCXX_CHECK_PTHREAD_RWLOCK_CLOCKLOCK], [ > [glibcxx_cv_PTHREAD_RWLOCK_CLOCKLOCK=no]) > ]) > if test $glibcxx_cv_PTHREAD_RWLOCK_CLOCKLOCK = yes; then > - AC_DEFINE(_GLIBCXX_USE_PTHREAD_RWLOCK_CLOCKLOCK, 1, [Define if > pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock are available in > .]) > + AC_DEFINE(_GLIBCXX_USE_PTHREAD_RWLOCK_CLOCKLOCK, (_GLIBCXX_TSAN==0), > [Define if pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock are > available in .]) > fi > > CXXFLAGS="$ac_save_CXXFLAGS" > > --0000000000002f80cb05fb5536c4--