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

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

Many thanks for the very useful information. 

regards
Morgan