This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Re: Adding a new thread model to GCC
- From: "lh_mouse"<lh_mouse at 126 dot com>
- To: "Jonathan Wakely"<jwakely dot gcc at gmail dot com>
- Cc: "gcc"<gcc at gcc dot gnu dot org>, "mingw-w64-public"<mingw-w64-public at lists dot sourceforge dot net>
- Date: Mon, 18 Apr 2016 00:56:45 +0800
- Subject: Re: Re: Adding a new thread model to GCC
- Authentication-results: sourceware.org; auth=none
- References: <2f3897eb dot bbc0e dot 1540ee9aa0b dot Coremail dot lh_mouse at 126 dot com><CAH6eHdQ2b_NLLC6Hyq=tKgXhgAEhTdV1d2+sv6enHN7wG4JESQ at mail dot gmail dot com>
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.
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.
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.
------------------
Best regards,
lh_mouse
2016-04-18