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

Subject: Re: [boost] [Review] Formal Review of Proposed Boost.Chrono LibraryStarts TOMORROW
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2010-11-10 04:39:08

Aaron Graham <aaron_at_[hidden]> 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