Boost C++ Libraries: Ticket #11377: Boost condition variable always waits for system clock deadline

attachment set

Fri, 05 Jun 2015 21:31:37 GMT

attachment → clock_changes.cpp

Test code to wait in various ways using boost threads/condition variables

attachment set

Fri, 05 Jun 2015 21:34:19 GMT

attachment → clock_changes_test.sh

Test harness to run clock_changes and set the system clock

attachment set

Fri, 05 Jun 2015 21:37:36 GMT

attachment → condition_variable_steady.hpp

condition_variable header rewritten to use steady clock instead of system clock

component changed

viboes — Sun, 07 Jun 2015 08:54:16 GMT

component threads → thread

Please, don't use the threads component but the thread one.

owner, status changed

viboes — Sun, 28 Jun 2015 08:56:45 GMT

owner changed from Anthony Williams to viboes
status new → assigned

viboes — Thu, 03 Sep 2015 07:19:59 GMT

Hi,

there is already a family of no_interruption_point sleeps that don't use condition variables

boost::this_thread::no_interruption_point::sleep_for
boost::this_thread::no_interruption_point::sleep_until

Does this fix you issue?

Could you resume what is the difference between your condition_variable_steady and the condition_variable?

Thu, 03 Sep 2015 15:46:41 GMT

Thanks for your attention.

Does this fix you issue?

Unfortunately, no. The issue is not with sleep operations, but with semaphore wait operations. When we wait on a semaphore and the system time changes, the wait does not return until the absolute time of the system clock reaches the deadline. Thus, if the system clock is set backwards while the process waits on a semaphore, the process may end up waiting longer than it should -- a 5 second wait may turn into a 1 minute wait if the system clock is set backwards by one minute. In our use case, we don't care about the absolute system time, we just want to time out after a specific duration.

Could you resume what is the difference between your condition_variable_steady and the condition_variable?

There is a minor change in condition_variable_steady to use the monotonic clock when initializing the semaphore and performing wait operations. This fixes the problem described above because the monotonic clock is not affected by changes in the system time.

viboes — Thu, 03 Sep 2015 21:00:24 GMT

Ok, I have adapted a patch from your condition_variable_steady that uses pthread_condattr_setclock. I have no platform providing it (I'm using MacOS). The user will need to define BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC until I find a way to detect it.

I will commit it soon on develop branch. Could you test it?

milestone changed

viboes — Thu, 03 Sep 2015 21:46:12 GMT

milestone To Be Determined → Boost 1.60.0

Add to develop branch https://github.com/boostorg/thread/commit/9f883f6ad7377b88b79fa70cc5de68cbfb0213e4

status, milestone changed

viboes — Sat, 05 Sep 2015 14:22:58 GMT

status assigned → new
milestone Boost 1.60.0 → To Be Determined

status changed

viboes — Tue, 08 Sep 2015 19:43:34 GMT

status new → assigned

Tue, 08 Sep 2015 21:31:18 GMT

Thanks for addressing this. I will try to help test.

As of 9/8, I'm unable to build the thread library from the master or develop branches:

$ ./b2 --with-thread
...
gcc.compile.c++ bin.v2/libs/thread/build/gcc-4.8/release/threading-multi/pthread/thread.o
In file included from ./boost/utility/result_of.hpp:202:0,
                 from ./boost/thread/detail/invoker.hpp:28,
                 from ./boost/thread/future.hpp:20,
                 from libs/thread/src/pthread/thread.cpp:19:
./boost/preprocessor/iteration/detail/iter/forward1.hpp:47:37: fatal error: boost/utility/detail/result_of_iterate.hpp: No such file or directory
 #        include BOOST_PP_FILENAME_1
                                     ^
compilation terminated.
    "g++"  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pedantic -pthread -fPIC -m64 -Wextra -Wno-long-long -Wno-unused-parameter -Wno-variadic-macros -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO -DBOOST_THREAD_POSIX -DNDEBUG  -I"." -c -o "bin.v2/libs/thread/build/gcc-4.8/release/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp"

I'm new to building boost from the git sources, so it's possible I'm doing something wrong. The chrono and system libraries build fine in my clone.

Tue, 08 Sep 2015 21:35:29 GMT

Replying to Dave Bacher <dbacher@…>:

As of 9/8, I'm unable to build the thread library from the master or develop branches:

Sorry, I checked the Boost.Thread Jenkins build and found I was missing the "headers" build step.

Tue, 08 Sep 2015 23:06:18 GMT

The patch is working properly for me.

With #define BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC, the test code waits for the specified duration even with the adjustment of the system clock. In the output below, the test completes after 5 seconds even though the system clock was adjusted backwards. Previously, the test would hang until the system clock reached the time the test was started plus 5 seconds.

$ sh clock_changes_test.sh
[sudo] password:
Setup sudo authentication
Starting test to wait for 5 seconds
Adjusting time to 01:00:00
Waiting for 5 sec
WAIT_UNTIL
Tue Sep  8 01:00:00 PDT 2015
Waiting...
Steady duration/start/stop: 5
   3104032404935 nanoseconds since boot / 3109032558479 nanoseconds since boot
System duration/start/stop: -52747 seconds
   1441751952904865440 nanoseconds since Jan 1, 1970 / 1441699204998073008 nanoseconds since Jan 1, 1970
Test complete, please check your system clock
Tue Sep  8 01:00:05 PDT 2015

Regarding when to use the monotonic clock, I think there are separate two issues:

Policy -- when should the monotonic clock be used? I would prefer that using the monotonic clock is the default. But perhaps other applications have other expectations.

Availability -- how to determine if the monotonic clock is available? On my Linux system, linux/time.h #defines CLOCK_MONOTONIC. At runtime, clock_gettime returns an error if the specified clock id is not available.

viboes — Thu, 17 Sep 2015 18:01:35 GMT

Thanks for checking the patch, and glad to see it works for you.

As soon as I'm able to detect if the following works as expected I will swithc the implementation on platforms supporting it.

  pthread_condattr_setclock(&attr, CLOCK_MONOTONIC);

viboes — Wed, 23 Sep 2015 23:01:58 GMT

Please could you try to replace in thread/v2/thread.hpp line #94

#ifdef BOOST_THREAD_SLEEP_FOR_IS_STEADY

#if defined BOOST_THREAD_SLEEP_FOR_IS_STEADY && ! defined BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC

milestone changed

viboes — Fri, 25 Sep 2015 05:40:54 GMT

milestone To Be Determined → Boost 1.60.0

Please, could you try the develop branch

https://github.com/boostorg/thread/commit/8f5de1d7c34ff7248261874f273498a622bf76d4

Fri, 25 Sep 2015 22:17:43 GMT

Replying to viboes:

Please, could you try the develop branch

https://github.com/boostorg/thread/commit/8f5de1d7c34ff7248261874f273498a622bf76d4

The latest develop branch works for my test case. My test code explicitly #defines BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC.

status changed; resolution set

viboes — Sun, 27 Sep 2015 13:42:14 GMT

status assigned → closed
resolution → fixed

https://github.com/boostorg/thread/commit/730cb550e6d969520c3f39e0ddf5d80351bddf3a