From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smarthost01b.ixn.mail.zen.net.uk (smarthost01b.ixn.mail.zen.net.uk [212.23.1.21]) by sourceware.org (Postfix) with ESMTPS id 0A03E3856DFB; Thu, 11 May 2023 12:19:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0A03E3856DFB Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=mcrowe.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mcrowe.com Received: from [88.97.37.36] (helo=deneb.mcrowe.com) by smarthost01b.ixn.mail.zen.net.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1px5Gl-0006NZ-Mk; Thu, 11 May 2023 12:19:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mcrowe.com; s=20191005; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=hLHWZeDkqpWWxmjPRULXU01dOX3NpKzqn588A5WX6M0=; b=aweNM AEMc8Qmxt/9Z91k+oWpZPBBa67d2Mc4k5XtPi9p4dODP6Jt8L2yiiJosRwgri56aMy5w6RWAZgbax mDPxOfyfe2VWZHtpWNUjkcW9McNcZQLWG8pEZRV4GaqwFJutxjJZyTnLniwpm5kDef5Jt7T42aUdN BZHf1gIS7MkPgLmqtR17WdcWy8QDnNz6dfrgLCK95vxd74Zx8cx5AIN6IRixwCfbmjBa6Rl720RNY sgyl/4lalYfKgXtj+nERXjVhzHUJKao/JwXcndBCSg0prxJoxQeFBFXY5orA0fIzO8c3S7gHdNK23 E4nzkRSPtgI+3oBwmMuKT0KUSyUdg==; Received: from mac by deneb.mcrowe.com with local (Exim 4.94.2) (envelope-from ) id 1px5Gl-0046F8-8V; Thu, 11 May 2023 13:19:39 +0100 Date: Thu, 11 May 2023 13:19:39 +0100 From: Mike Crowe To: Jonathan Wakely Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [RFC] libstdc++: Do not use pthread_mutex_clocklock with ThreadSanitizer Message-ID: References: <20230510112009.633444-1-jwakely@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-smarthost01b-IP: [88.97.37.36] Feedback-ID: 88.97.37.36 X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,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: 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++ < > 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). 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 .]) > > + AC_DEFINE(_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT, (_GLIBCXX_TSAN==0), > > [Define if pthread_cond_clockwait is available in .]) > > 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.