[boost] [chrono] [thread] boost.chrono changes to boost::condition_variables

Subject: [boost] [chrono] [thread] boost.chrono changes to boost::condition_variables
From: Morgan Henry (Morgan.Henry_at_[hidden])
Date: 2010-07-22 10:34:39

Hello,

I've been exploring the boost.chrono candidate library as a basis for some fixes to boost::condition_variables::timed_wait().

I have some questions:
1) What is the current state of the chrono library, and its likely path into boost?
2) Are the chrono API changes to boost::condition_variables likely to be accepted into the boost.thread library in their current form?
    (i.e introduction of wait_for(), wait_until(), and the introduction of a new explicit dependency from boost/thread/condition_variables on chrono::time_point etc...)
3) Are there any other planned changes to boost::condition_variables::timed_wait to allow use of POSIX clocks other than CLOCK_REALTIME?

My ultimate goal is to provide an implementation of boost::condition_variables that allows access to the POSIX clock CLOCK_MONOTONIC 
for use through boost::condition_variables::timed_wait().
Specifically, providing an implementation that uses 
    pthread_condattr_setclock(&attr, CLOCK_MONOTONIC) at boost::condition_variables initialisation,
and use of 
    pthread_cond_timedwait(..., &t) with clock_gettime(CLOCK_MONOTONIC, &t) in boost::condition_variables::timed_wait() and friends
This change would provide reasonable behaviour of boost::condition_variables::time_wait() in presence of ongoing changes to the system clock.  

boost.chrono contributes to this goal by providing a clock abstraction and accessors to the appropriate POSIX clocks through 
class monotonic_clock, class system_clock, etc...

Further to this, changes to boost::condition_variable::timed_wait() and similar would be required to use
clock_gettime(CLOCK_MONOTONIC, &t) rather than boost::get_system_time() for calculations when the monotonic_clock is specified.

I'm currently considering whether to trust that the boost.chrono API changes to the boost::condition_variables API are robust, and likely to 
persist for the future.  Or to propose alternative changes localised to boost::condition_variables that achieve the goals above without the 
strong dependency on boost.chrono.

Thanks for any comments or information about the above.
Morgan

http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.