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
