Boost logo

Boost :

Subject: Re: [boost] [chrono] [thread] boost.chrono changes to boost::condition_variables
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2010-07-22 19:22:37


On Jul 22, 2010, at 10:34 AM, Morgan Henry wrote:

> 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.

Fwiw, boost::chrono is modeled after std::chrono set to be standardized in C++0X:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf

Though this document is a final candidate draft, not a standard, I consider the <chrono> API fairly stable in this draft.

-Howard


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk