Re: [boost] [Review] Formal Review of Proposed Boost.Chrono LibraryStarts 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. 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.
----- Original Message ----- From: "Aaron Graham" <aaron@aarongraham.com> To: <boost@lists.boost.org> 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
Aaron Graham <aaron@aarongraham.com> writes:
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.
That is a problem with the implementation of condition_variable::wait_until rather than monotonic_clock. My commercial Just::Thread library provides an implementation of std::condition_variable that works correctly with both monotonic_clock and system_clock on Linux and Windows. It does rely on recent versions of the linux kernel though (>=2.6.19 IIRC). The boost::condition_variable implementation is a wrapper around pthread_cond_wait, and will continue to have difficulties with using different clocks --- you can either do all waits on the monotonic clock (assuming there is one) or all waits on the system clock. Anything else has to convert. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
participants (3)
-
Aaron Graham -
Anthony Williams -
vicente.botet