On 17 April 2016 at 17:56, lh_mouse <lh_mo...@126.com> wrote: > A glance over gthr.h reminds me __gthread_time_t. There seem few requirements > documented in gthr.h. > I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago. > > Specifically, here are the two questions: > 0) Should __gthread_time_t be a struct or a plain integral type? > The 'struct timespec' used by pthread is a struct introduced in POSIX. > However my implementation uses a plain uint64_t.
I don't see why it has to be a struct, it just has to be suitable as an argument to the relevant __gthread functions. If the current code assumes a struct and the Windows API calls need an integer then either the existing code needs to be made more flexible, or you need to define it as a struct and then convert to an integer inside your new gthread wrapper functions. > 1) How to obtain a __gthread_time_t representing the current time? > According to Linux man pages, the timeout parameter of > pthread_cond_timedwait() is the same as gettimeofday() - that is, it uses the > wall clock. > My implementation uses GetTickCount64() - that is, my implementation uses a > monotonic clock. std::condition_variable::__clock_t must be a typedef for the clock used by the underlying implementation, so it sounds like you should use std::chrono::steady_clock for your thread model. > Quoting from ISO/IEC WG21 Draft N4582 (C++1z): > [quote] > 30.4.1.3.1 Class timed_mutex [thread.timedmutex.class] > ... > template <class Rep, class Period> > bool try_lock_for(const chrono::duration<Rep, Period>& rel_time); > template <class Clock, class Duration> > bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time); > ... > [/quote] > the std::timed_mutex::try_lock_for() function template shall accept any clock > type, hence we have to do timestamp translation. It is also important to know > how libstdc++ handles this. All conversions are done using the std::chrono facilities, before any conversion to __gthread_time_t. That means the conversions are portable.