Subject: Re: [boost] [chrono] [thread] boost.chrono changes to boost::condition_variables
From: Morgan (morgan.henry_at_[hidden])
Date: 2010-07-26 08:48:31
Howard Hinnant <howard.hinnant <at> gmail.com> writes:
> [thread.req.timing]/2 says:
> > The member functions whose names end in _for take an argument that specifies
> a relative time. Implementations should use a monotonic clock to measure time
> for these functions. [ Note: Implementations are not required to use a
> monotonic clock because such a clock may not be available. â end note ]
> In English: wait_for should always use a monotonic clock under the hood,
> unless the platform doesn't have one.
Ah! Enabling and enforcing the use of the monotonic clock for relative timeouts
feels instinctively correct; and just what I was after.
> 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
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.
Many thanks for the very useful information.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk