On Jul 26, 2010, at 8:48 AM, Morgan wrote:
Templating the condition_variable on clock_type was specifically avoided for std::condition_variable because a condition_variable often has more than one waiting client at a time, and it was felt that those different waiting clients should be able to use different clocks simultaneously when waiting on a (absolute) time_point.
Of course; you are correct.
I was being misled by the existing pthread implementation of boost::condition_variables and boost::chrono which currently enforces a single clock on all clients of a condvar.
This limitation seems to have been inherited from pthread_cond_timedwait and pthread_cond_init which do not provide the fexibility for mixing of clock types for waiting clients of a cv. (The pthread_cond clock type is fixed at condvar creation).
Fixing this limitation would now seem to be a problem for the pthread platform implementation, rather than the boost API and the standard.
I'll propose some changes to boost::chrono pthread implementation in line with the draft standard.
There's more info on this topic here: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#887 -Howard