This is the mail archive of the
mailing list for the libstdc++ project.
Re: [RFC 1/2] gthread: Add __gthread_cond_timedwaitonclock
- From: Mike Crowe <mac at mcrowe dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Mon, 6 Jul 2015 15:10:52 +0100
- Subject: Re: [RFC 1/2] gthread: Add __gthread_cond_timedwaitonclock
- Authentication-results: sourceware.org; auth=none
- References: <1436187340-12164-1-git-send-email-mac at mcrowe dot com> <20150706135142 dot GA13663 at redhat dot com>
On Monday 06 July 2015 at 14:51:42 +0100, Jonathan Wakely wrote:
> On 06/07/15 13:55 +0100, Mike Crowe wrote:
> >diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h
> >index fb59816..0e01866 100644
> >--- a/libgcc/gthr-posix.h
> >+++ b/libgcc/gthr-posix.h
> >@@ -33,6 +33,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
> >#define __GTHREADS_CXX0X 1
> >#include <pthread.h>
> >+#include <time.h>
> >#if ((defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)) \
> > || !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK))
> >@@ -44,6 +45,11 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
> ># endif
> >+#if defined(_GLIBCXX_USE_PTHREAD_COND_TIMEDWAITONCLOCK_NP)
> >+# define _GTHREAD_USE_COND_TIMEDWAITONCLOCK 1
> This isn't correct, because it's possible to include <gthr.h> before
> including any C++ Standard Library header, so the _GLIBCXX_ macro
> defined in libstdc++'s c++config.h will not have been defined.
Presumably gthr-posix.h could just include c++config.h to avoid that, but
perhaps it's not that simple which is why gthr-posix.h swings through hoops
to define _GTHREAD_USE_MUTEX_TIMEDLOCK itself?
> It might make sense to just do this internally in libstdc++ and not
> involve gthr-posix.h at all, this is what we do for pthread_rwlock_t
> usage in <shared_mutex> so you might want to follow that model.
I implemented the new function in gthreads because that seemed to be what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 was suggesting and I'd
incorrectly assumed that there were non-pthreads backends for gthreads too.
I'm can try and re-implement condition_variable using pthreads directly but
the change will be somewhat larger and it would break non-pthreads
> How portable is pthread_cond_timedwaitonclock_np? Is it unique to
> glibc or do any other posix systems provide it?
It's not at all portable; I invented it because it seemed to be the most
straightforward way to correctly support std::condition_variable's wait
operations using std::chrono::steady_clock on Linux. I haven't even
suggested adding the function on the glibc mailing list yet.
I looked briefly to see if I could find anyone else solving the problem on
Posix platforms but they all seem to be converting to system_clock too. :(