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 F3BEE3858C66 for ; Wed, 10 May 2023 11:31:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F3BEE3858C66 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=1683718286; 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=R5VaJ5ySn0nBUYAN+Qkb/fG9I9hTruq+3zHm/8tOiGwmK9MFzA3v2nKCISSg75msWqpMdt uhORcLZrTkQ/p4QvuRGV3Yygs+J0vtKeC3DIywULRih1y05ZeuTIpTcZWQIiFgEFiBTOus +cZRaF3rUwpm5oVmQqQGzEMVF0C8lg8= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-55-Mq8gvojQMUKpbSSA3h0o_g-1; Wed, 10 May 2023 07:31:25 -0400 X-MC-Unique: Mq8gvojQMUKpbSSA3h0o_g-1 Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-2ad94975f84so17437311fa.1 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=LFQaAtY8nLhX8tz34rZflHui90bKz4kTZdkHJMx0l3n+ybLz6IWiayVpha+ANQu+Oe YTPSsqT4WzXplWNc+4BUAMsQChLZUT47v4x26YoUCWc+DuZbruGZVI93oYi5OZViIBNe GS+UHUHMiG6F8VOY/QXnTlq0bhgTEHIHKwzzbjoFhNHGO7bSp1jMpAM0mPe7fKPbQpFc y11FkKPD1ibMGbzTzwacAV6IHAx0iNwTaTub4I4JAAp7JFsmY+7js/PrFt+I/ztLQpiX Nz6zJq2xG00VCwiT99eIv38LnPxobQu349uQr5+ZeoT9MWv1OTu5I72ms0itp+0iBdGU 7xeQ== X-Gm-Message-State: AC+VfDzZrEwtL08zt/dhq4nHxH46FptAHe7MNgeZf9IvIUXb/yRT7crQ Ufw74cISo//Fu07FddH0V2Sy+KdEDhvaykBkKoRZn84swXvTv1DfSr3F70kAi2C9r5mqzh+e1M7 ZsD8DaSlb8x4TYBu4rx9KqN6E2Py4uPs= X-Received: by 2002:a2e:b172:0:b0:2a7:8150:82c1 with SMTP id a18-20020a2eb172000000b002a7815082c1mr1856281ljm.38.1683718283793; 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.0 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=ham 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--