id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
11377,Boost condition variable always waits for system clock deadline,Dave Bacher <dbacher@…>,viboes,"On Linux systems using pthreads, the Boost condition variable wait operations are always converted to use the system clock as a time base. This causes problems when the system clock is changed. When the system clock is set back during the wait, the wait operation does not return until the system clock has returned to the absolute time calculated when the wait operation was scheduled. 

The attached test code and test harness demonstrates this behavior. On my Ubuntu Linux 14.04 system, the test code (when run with the 'until' or 'for' wait operations) hangs after the harness sets the system clock. 

(see attached test case: build clock_changes and run clock_changes_test.sh)

g++ -g -Wall -o clock_changes clock_changes.cpp -I/tools/boost_1_56_0 -L/tools/boost_1_56_0/stage/lib -lboost_thread -lboost_chrono -lboost_program_options -lboost_system -lpthread


In our application (and I suppose in a variety of use cases), the application wants to wait for a time relative to a monotonic clock regardless of the behavior of the system clock. 

The boost sleep operations demonstrate the correct behavior in the face of system clock changes. 

The Pthread API supports using a monotonic clock for timed waits by setting the clock when the condition variable is initialized. And Issue 7665 seems to imply that condition_variable will be changed to use a monotonic clock: 
https://svn.boost.org/trac/boost/ticket/7665#comment:16

In case it's useful, I have attached a modification to boost::condition_variable to create a new class boost::condition_variable_steady that behaves consistently in the face of system clock changes. 

(see condition_variable_steady.hpp)

I'm not sure what the right behavior should be in boost, but I would suggest at least providing a class that operates independently of the system clock. 

Note: I'm currently using boost 1.56.0, but the condition_variable.hpp header is effectively the same in 1.57.0 and 1.58.0, so I'm almost certain the same issue exists in the most recent release (1.58.0). 
",Bugs,closed,Boost 1.60.0,thread,Boost 1.56.0,Problem,fixed,"condition variable, clock",