boost::this_thread::sleep_for() sometimes returns immediately on win32

[Lars Hagström <lars@…>]

I have observed one instance of boost::this_thread::sleep_for returning immediately instead of waiting for the specified time. This happened on a Windows 7 32 bit machine, with Boost 1.55 and VS2012. Another relevant thing might be that it is a VM with 2 cpus running in XenServer 6.2.

Attached is my test program, that starts a bunch of threads that all do a sleep_for(10 minutes). Main then immediately interrupts and joins the threads. The threads all check whether they timed out or whether they were interrupted. In case they time out we print the elapsed time, which of course is expected to be 10 minutes.

Here is the output of my test program:

first test
Timeout!
Elapsed time:  0.000039s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%)
.

I'm thinking that this could be something to do with the well known strangeness of QueryPerformanceCounter (see for example #8006). The VM host was probably under a fair bit of load at the time this test failed.

[Lars Hagström <lars@…>]

Test of this_thread::sleep_for and interruption.

[viboes]

Please could you rework the example without using boost::timer and using a steady_clock or high_resolution_clock?

[viboes]

Could you try this one using the develop branch?

[Lars Hagström <lars@…>]

I've now got this happening regularly. It appears to only happen at the very start of running the program. So I've rewritten it with just chrono and no timers, and also added a python script that runs it repeatedly.

Can be found here (an svn repo): ​http://svn.code.sf.net/p/safir/svn/misc/boost_sleep_test/

Anyway, this now fails quite quickly on a VM like the one I described above.

Timeout!
Elapsed time: 601116317640 nanoseconds.

Will try with the develop branch "soon" (am home with sick kid atm).

[Lars Hagström <lars@…>]

I just realized what the problem is!

It's not a QPC problem after all. It's the static in steady_clock::now. I've got 50 threads trying to initialize that static variable at the same time, of course things go wrong :-)

No idea of how to fix it in an efficient manner, though.

[viboes]

Replying to Lars Hagström <lars@…>:

I just realized what the problem is!

It's not a QPC problem after all. It's the static in steady_clock::now. I've got 50 threads trying to initialize that static variable at the same time, of course things go wrong :-)

No idea of how to fix it in an efficient manner, though.

Do you mean the static in

    static double nanosecs_per_tic = chrono_detail::get_nanosecs_per_tic();

Could you try removing the static keyword?

  steady_clock::time_point steady_clock::now() BOOST_NOEXCEPT
  {
    double nanosecs_per_tic = chrono_detail::get_nanosecs_per_tic();

[Lars Hagström <lars@…>]

Yes, that is exactly the one I mean.

I've removed the static keyword and it works very well now.

[viboes]

Thanks, I have changed to Chrono. I will propose you a complete patch soon.

[viboes]

​https://github.com/boostorg/chrono/commit/318e5f24297977d1bc126d2cd7ac65effe1cb7b7

[Lars Hagström <lars@…>]

That certainly works. Thanks!

[viboes]

​https://github.com/boostorg/chrono/commit/dfb7bc71c9728e5b8e9bbc0679b95a46f4cbb0ba

[Smithe329]

If you are going for best contents like myself, simply go to see this site all ekebkcegekkdbdde

[anonymous]

When are you guys going to fix it?

[viboes]

Smithe329, we can be wrong when we do some changes on the Trac. This doesn't mean that you don't need to be polite.

[viboes]

It seems this is related to #9856 and #10967.

[viboes]

anonymous please, if this is not working for you give more information. This was fixed as Lars said "That certainly works. Thanks!".