Talk specifically about C++ std::timed_mutex: 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]
Merely, I haven't used timed_mutex. According to this specification, std::timed_mutex shall work with not only a specific, but actually ANY clock type. That is to say, we are always going to perform timestamp translation no matter what clock type we use. And that is also the reason why I have decided to use a 'sane', monotic clock type. The fact that gthread isn't pthread thus isn't subject to convention of 'struct timespec' also gives us the right to do so. It is still how to obtain a __gthread_time_t that represents the current system time that the problem is. ------------------ Best regards, lh_mouse 2016-04-15 ------------------------------------------------------------- 发件人：Adrien Nader <[email protected]> 发送日期：2016-04-14 19:42 收件人：mingw-w64-public 抄送： 主题：Re: [Mingw-w64-public] Adding a new thread model to GCC On Thu, Apr 14, 2016, lh_mouse wrote: > C++0x threading APIs are currently unimplemented. > > It is only because gthr.h is so obscure about __gthred_time_t. > It doesn't say anything about whether __gthread_time_t should be a struct > (like struct timespec) or a plain integer or even a floating point type, > neither does it say where and how to obtain a __gthread_time_t that > represents the current system time. > Nonetheless, all *timedwait() interfaces, for mutex, condition variable and > (as extensions) even thread and once-init, are naturally supported by > mcfgthread. > > I really hate the 'struct timespec' thing, as well as using a UNIX timestamp > in *_timedwait() functions because the wall clock is subject to DST and NTP > and can also be manually set by the user. > Rather, (currently) all timepoints in mcfgthread are obtained using the > _MCFCRT_GetFastMonoClock() function which is simply a wrapper for > GetTickCount64() that is only available since Vista. > This guarantees that the clock is monotonic and can't be set by the user, as > well as a good resolution of 1ms. > > However, should readjusting the time origin be essential, it would be easy to > use an alternative clock, code about which could be found here: > https://github.com/lhmouse/mcfgthread/blob/master/src/env/_nt_timeout.h?ts=4#L15 The use of unix timestamps and the clock choice are completely orthogonal issues. CLOCK_MONOTONIC can be happily used with unix timestamps. If it couldn't, then I wonder why the REALTIME, REALTIME_COARSE, MONOTONIC, MONOTONIC_COARSE, RAW, BOOTTIME, PROCESS_CPUTIME_ID, THREAD_CPUTIME_ID clocks would have been added to glibc (well, except thread cputime :) ). If you want to use a specific clock with says pthread_cond_timedwait, you should set the corresponding attribute on the condition variable with pthread_condattr_setclock(). I'm not sure you (or someone else) would start implementing C++11 threading on top of that but as far as I know, C++, at least C++11, gives absolutely no guarantee on the clock being used. It's not even that you can't rely on a monotonic one being available, it's that you can't rely on the dumbest one being available and you cannot chose nor check anything about clocks. What you are doing here is using your own preference. I agree it makes much more sense but you shouldn't chose a behaviour based on that, especially when the most-widespread behaviour does the opposite. -- Adrien Nader ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
