Boost C++ Libraries: Ticket #7665: this_thread::sleep_for no longer uses steady_clock in thread

attachment set

ewdevel@… — Thu, 08 Nov 2012 14:40:14 GMT

attachment → sleep_for_test.cpp

Test for sleep_for that fails when time is changed.

owner, status changed

viboes — Thu, 08 Nov 2012 18:25:30 GMT

owner changed from Anthony Williams to viboes
status new → assigned

Which platform and compiler are you using?

viboes — Thu, 08 Nov 2012 21:52:18 GMT

Hi, I have checked your program on MacOs gcc-4.2.1, and I'm unable to reproduce the behavior you reported

gt-s8600:test viboes$ date
Jeu  8 nov 2012 22:00:03 CET
gt-s8600:test viboes$ ./a.out
Main thread START
Sleeping for 10 seconds - change time
Main thread END
Ended
gt-s8600:test viboes$ date
Jeu  8 nov 2012 10:10:06 CET

I have changed the date to 10:10

Tue, 13 Nov 2012 10:52:52 GMT

It seems that mac version [guessing from boost/chrono/detail/inlined] uses different sources for time keeping.

I've been able to reproduce this bug under: CentOS 6.2 x64 [gcc 4.4.6] VirtualBox'ed Ubuntu 10.04 x64 [gcc 4.6.1]

Can someone check this under different linux distros?

viboes — Wed, 14 Nov 2012 18:33:34 GMT

Replying to Eryk Wieliczko <ewdevel@…>:

It seems that mac version [guessing from boost/chrono/detail/inlined] uses different sources for time keeping.

I've been able to reproduce this bug under: CentOS 6.2 x64 [gcc 4.4.6] VirtualBox'ed Ubuntu 10.04 x64 [gcc 4.6.1]

OK I will check.

viboes — Sun, 25 Nov 2012 09:03:17 GMT

I don't know if there is a regression in trunk of Boost.Thread on Ubuntu as a lot of tests are failing independently of setting the date. It is surprising that the code is working on Ubuntu 12.04-64 testers. I'll continue the analysis.

summary, milestone changed

viboes — Sat, 01 Dec 2012 11:42:41 GMT

summary this_thread::sleep_for no longer uses steady_clock in thread → l
milestone To Be Determined → Boost 1.53.0

I've made some changes on the sleep_for algo depending on BOOST_THREAD_SLEEP_FOR_IS_STEADY is defined or not. have you the possibility to check if this rework solves the issue?

Committed in trunk [81649]

summary changed

viboes — Sat, 01 Dec 2012 11:45:49 GMT

summary l → sleep_for doesn't use steady_clock

summary changed

viboes — Sat, 01 Dec 2012 11:46:19 GMT

summary sleep_for doesn't use steady_clock → this_thread::sleep_for no longer uses steady_clock in thread

status changed; resolution set

viboes — Tue, 11 Dec 2012 22:19:29 GMT

status assigned → closed
resolution → fixed

I hope the modification fixes the bug. Reopen it if you see the issue on 1.53 or on trunk.

Volker_pruess@… — Fri, 04 Apr 2014 08:30:19 GMT

I think this needs to become reopened. We observe regression with boost 1.54.0, 1.55.0 and latest git version. Additionally the discussion #6787 also points in this direction.

We're using Ubuntu 12.04.4 LTS 64 bit for x86.

viboes — Fri, 04 Apr 2014 22:08:38 GMT

And what do you think of the proposition in #6787?

status changed; resolution deleted

viboes — Fri, 04 Apr 2014 22:09:38 GMT

status closed → reopened
resolution fixed

Mon, 07 Apr 2014 13:21:10 GMT

I'm not quite sure about the solution you proposed but I see the problem :

'boost::this_thread::sleep_for' has to remain an interruption point
there are no standard library or pthread functions allowing interuptible operation based upon a stable clock, especially for a portable library.

I checked against the c++ library provided alongside with the gcc 4.6.3 and at least their implementation of sleep_for is not affected by changes in the system clock. It seems that the gcc implementation is based upon nanosleep (http://stackoverflow.com/questions/12523122/what-is-glibcxx-use-nanosleep-all-about), IMHO therefore not interruptible.

I'm not quite sure whether an implementation of sleep_for (and sleep) that is affected by changes made to the system clock would be acceptable anyway. And moving sleep_for out of the namespace 'this_thread' would break existing code.

Seems to be a question for the standard library experts ...

viboes — Mon, 07 Apr 2014 16:50:04 GMT

The standard doesn't includes interruptible threads. And Boost can do whatever we decide without the standard library experts advice ;-)

So it is up to you to decide if we want additional non-interruptible functions or not. By compatibility, we can not replace the current behavior.

Tue, 08 Apr 2014 07:51:31 GMT

When you refer to the current behaviour you mean that boost::this_thread::sleep_for has been mentioned in the list of predefined interruption points ? The documentation about sleep_for also says

Suspends the current thread until the duration specified by by rel_time has elapsed.

Question is which clock is used to measure the duration. I would expect that most programmers would intuitively expect a stable clock here. But referring to the type of clock in the documentation would do it. So I would agree to your suggestion adding another set of methods.

Thu, 10 Apr 2014 08:23:06 GMT

I saw that sleep_for is using pthread_cond_wait to achieve thread suspension and being interruptible. Is it possible to initialize the condition variable to use the monotonic clock as described here ?

viboes — Sun, 06 Jul 2014 10:13:24 GMT

I was not aware of pthread_condattr_setclock. I will adapt condition_variable to use it on the platforms providing it.

Thanks for the pointer.

viboes — Sun, 06 Jul 2014 11:17:45 GMT

Unfortunately pthread_condattr_setclock is not available on MacOs?.

milestone changed

viboes — Sun, 07 Sep 2014 07:58:52 GMT

milestone Boost 1.53.0 → To Be Determined

milestone changed

viboes — Wed, 10 Sep 2014 11:50:49 GMT

milestone To Be Determined → Boost 1.57.0

https://github.com/boostorg/thread/commit/02bc292c201e6146ba18e05699d0a5c62f540a5b

status changed; resolution set

viboes — Tue, 16 Sep 2014 06:20:30 GMT

status reopened → closed
resolution → fixed

status, milestone changed; resolution deleted

viboes — Thu, 03 Sep 2015 20:56:27 GMT

status closed → reopened
resolution fixed
milestone Boost 1.57.0 → To Be Determined

I'm writing a patch that uses pthread_condattr_setclock. As I said 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.

Is there any one that can test it?

milestone changed

viboes — Thu, 03 Sep 2015 21:45:30 GMT

milestone To Be Determined → Boost 1.60.0

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

status changed

viboes — Sat, 05 Sep 2015 14:20:33 GMT

status reopened → new

milestone changed

viboes — Sat, 05 Sep 2015 14:23:06 GMT

milestone Boost 1.60.0 → To Be Determined

status changed

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

status new → assigned

viboes — Wed, 23 Sep 2015 23:03:17 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

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

Please, could you try the develop branch

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

milestone changed

viboes — Fri, 25 Sep 2015 05:43:12 GMT

milestone To Be Determined → Boost 1.60.0

mail@… — Fri, 25 Sep 2015 22:40:04 GMT

I'm experiencing the same problem (Linux Mint, 3.13.0-37-generic # 64-Ubuntu SMP, boost 1.54).

Can confirm that the threads are behaving differently with the test code.

Checked out modular-boost, switched to develop for boost-thread, compiled everything and tried the test code above. Adding

#define BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC 1

fixes the bug for me.

viboes — Sun, 27 Sep 2015 12:22:42 GMT

Thanks for the report.

status changed; resolution set

viboes — Sun, 27 Sep 2015 13:40:29 GMT

status assigned → closed
resolution → fixed

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