Re: [v3] c++0x timed wait's in <condition_variable>

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi Chris,

finally I found the time to study a bit these issues...

> Issue:
> std::condition_variable can't use std::chrono::system_clock if
> _GLIBCXX_USE_CLOCK_MONOTONIC is defined because it requires
> pthread_condattr_setclock et. al. to be implemented somehow in the
> gthreads backend.
>
> Solution A) put in the condattr pthreads functions into the gthreads  
> backend.
> Issues with A) how well do the pthread attribute classes map to
> non-pthread threading systems? My guess... not very well.

I understand, but I think that in principle we can delay this issue:  
if it turns out that the other threading systems have trouble  
implementing these POSIX facilities, a macro can be added to the gthr- 
* files and our implementation can dispatch on it.

> Solution B) Don't use a monotonic clock.
> Issues with B) Currently if _GLIBCXX_USE_CLOCK_MONOTONIC there is no
> non-monotonic clock since system_clock uses CLOCK_MONOTONIC and
> monotonic_clock and high_resolution_clock are just typedef's.
>
> This patch solves the issue with solution B.
>
> If _GLIBCXX_USE_CLOCK_MONOTONIC is defined, monotonic_clock is a
> separate class instead of a typedef. system_clock only ever uses the
> clock_gettime(CLOCK_REALTIME,...), gettimeofday or std::time and never
> clock_gettime(CLOCK_MONOTONIC).
>
> Thus, condition_variable can use system_clock as its internal clock
> and although its never monotonic, there's no need for
> pthread_condattr_setclock et. al. and it all just works :)

I have some concerns. First, do we have a reference in the POSIX  
documents clarifying that the default for this attribute is definitely  
REALTIME? Otherwise the whole plan B seems brittle to me... Also, I'd  
like to understand in better detail why exactly we had a monotonic  
clock as our first choice for system_clock.  And also whether we have  
or nor reasons to believe that,  on systems providing clock_gettime  
indeed, a monotonic clock is less likely to be available than a  
realtime clock.

Reading the pthread_cond_timedwait, pthread_cond_wait page in POSIX, I  
see that the examples use the realtime clock, but given the absolute  
time measure, I think scenarios could be imagined where a monotonic  
clock would have advantages. Comments about that? Probably this is the  
most important technical choice, because, if I understand correctly, a  
user of the C++0x condition_variable, at variance with the C, POSIX  
one, doesn't have the option to choose, we must decide for him which  
one is better!

Therefore, all in all, I think we should wait a bit before going with  
solution B. Depending on your point of view about the above issues we  
can certainly do it, but we can also try to push the gthread changes,  
which seem rather small to me. Maybe we'll have to do that anyway, as  
soon as possible, maybe not for  4.4.0, because we cannot be sure  
about the default for the attribute (see above)...

Paolo.