Re: [boost] [Review] Formal Review of Proposed Boost.ChronoLibraryStarts TOMORROW

Subject: Re: [boost] [Review] Formal Review of Proposed Boost.ChronoLibraryStarts TOMORROW
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-11-09 20:00:07

----- Original Message ----- 
From: "Aaron Graham" <aaron_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, November 10, 2010 12:47 AM
Subject: Re: [boost] [Review] Formal Review of Proposed Boost.ChronoLibraryStarts TOMORROW

> See this gcc bugzilla entry for a discussion I've had about chrono support
> in the gcc implementation.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
> 
> Unfortunately, monotonic_clock support, even if it exists, is a transparent
> lie. It's not so much a problem with the chrono library as it is a problem
> with the thread library's use of chrono. A monotonic clock is used to
> provide somewhat accurate/reliable wait times even in the face of changing
> clocks, especially in the case of mutexes and condition variables.
> 
> When condition::wait_until is called with a monotonic_clock time_point, that
> time_point is translated to a system_clock time_point. If the system_clock
> is changed (via NTP, adjtime, settimeofday, etc) between when
> convert_to<system_clock> is called and when the underlying posix call is
> made, the very reason for using monotonic_clock defenestrates and splatters
> all over the pavement. Depending on the magnitude of the clock change,
> wait_until could hang forever.
> 
> In my opinion, all convert_to calls in the thread library should go to the
> monotonic_clock, if available. Not system_clock. I couldn't get the gcc
> people to understand this, so I won't be able to use <chrono> in the
> standard library sans modification. Maybe boost will get it right?
> 
> Let me know if I'm missing a subtle point that moots my concerns.

You are right. There is a TR that will interest you (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html) . The main problem with the Thread library is that it depends on the interfaces the platform provides. The pthread interface doesn't provides timeout functions with a monotonic/steady clock, so the Thread implementations use the single clock that can be used , i.e. the system_clock. I don't think there is a workaround (other than polling) without changes in the interfaces of the underlying platform :( Maybe Anthony or Howard have a solution?)

If I'm not wrong the windows API allows to use monotonic clocks for the timeout operations.
 
> Other than that, I think the this library is great. I need it badly. I
> haven't looked over all the code yet, but what I've seen looks good.

Thanks, 
Vicente