This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC 1/2] gthread: Add __gthread_cond_timedwaitonclock


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
> >#endif
> >
> >+
> >+#if defined(_GLIBCXX_USE_PTHREAD_COND_TIMEDWAITONCLOCK_NP)
> >+# define _GTHREAD_USE_COND_TIMEDWAITONCLOCK 1
> >+#endif
> 
> 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
platforms.

> 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. :(

Thanks.

Mike.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]