public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Cc: Mike Crowe <mac@mcrowe.com>
Subject: [RFC] libstdc++: Do not use pthread_mutex_clocklock with ThreadSanitizer
Date: Wed, 10 May 2023 12:20:09 +0100	[thread overview]
Message-ID: <20230510112009.633444-1-jwakely@redhat.com> (raw)

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.

-- >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 <pthread.h>.])
+    AC_DEFINE(_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT, (_GLIBCXX_TSAN==0), [Define if pthread_cond_clockwait is available in <pthread.h>.])
   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 <pthread.h>.])
+    AC_DEFINE(_GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK, (_GLIBCXX_TSAN==0), [Define if pthread_mutex_clocklock is available in <pthread.h>.])
   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 <pthread.h>.])
+    AC_DEFINE(_GLIBCXX_USE_PTHREAD_RWLOCK_CLOCKLOCK, (_GLIBCXX_TSAN==0), [Define if pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock are available in <pthread.h>.])
   fi
 
   CXXFLAGS="$ac_save_CXXFLAGS"


             reply	other threads:[~2023-05-10 11:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-10 11:20 Jonathan Wakely [this message]
2023-05-10 11:31 ` Jonathan Wakely
2023-05-11 12:19   ` Mike Crowe
2023-05-11 12:42     ` Jonathan Wakely
2023-05-11 20:52       ` [PATCH v2] " Jonathan Wakely
2023-05-12 10:30         ` Mike Crowe
2023-05-12 10:32           ` Jonathan Wakely
2023-05-15 12:03             ` Mike Crowe
2023-05-15 19:58         ` Thomas Rodgers
2023-05-11 15:54     ` [RFC] " Thomas Rodgers
2023-05-11 16:04       ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230510112009.633444-1-jwakely@redhat.com \
    --to=jwakely@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    --cc=mac@mcrowe.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).