Subject: [boost] [thread] Can boost::this_thread::sleep_for() totally stop the thread?
From: Klaim - JoÃ«l Lamotte (mjklaim_at_[hidden])
Date: 2013-07-29 04:11:42
I'm having, sometime, trouble with a rare heisenbug (rare but appearing
several times a week).
I described it there:
There I ask if it's possible for windows to totally stop a thread that is
sleeping too often.
As I'm using boost::thread for sleeping this specific thread that, for
unknown reason, sometime totally stop working, I'm also wondering if the
boost::this_thread() implementation could not be doing
something that the OS might not like?
I'll report the content of the page here:
Can Windows totally stop a thread if it's sleeping too often?
I have a rare heisenbug in a multi-threaded application where the main
thread, and only this thread, will just do nothing. As it's an heisenbug
it's really hard to understand why this is happening.
The main thread is basically just looping. In the loop, it check several
concurrent priority queues which contain tasks ordered by time to be
executed. It pop a task, see if it's time to execute it. If it's time, it
will just schedule it into TBB's task scheduler (using a root task which is
the parent of all other tasks). If it's not time, the task is pushed again
in the priority queue.
That's for one cycle. At the end of the cycle, the main thread is put to
sleep for a very short time that I expect will be longer in practice but
it's not really a problem, I just don't want it to use too much resources
when not necessary.
static const auto TIME_SCHEDULED_TASKS_SPAWN_FREQUENCY = microseconds(250);
while( !m_task_scheduler.is_exiting() ) // check if the application should
m_clock_scheduler.spawn_realtime_tasks(); // here we spawn tasks if it's
this_thread::sleep_for( TIME_SCHEDULED_TASKS_SPAWN_FREQUENCY );
I have a special task that just log a "TICK" message each second. It is
automatically rescheduling until the end of the program. However, when the
heisenbug appear, I can see the "TICK" disappearing and the application not
doing anything else than the work that occurs in non-main threads. So it
appear that only the main thread is touched.
The problem can come from different places, maybe in the scheduling logic,
but then it's also the only thread that have a sleep call. That sleep is a
My question is: **Is it possible that Windows (7 64bit) consider the main
thread to be sleeping often and decide that it should sleep for a longer
period of time than asked or be definitely ended?**
I expect that it is not possible but I would like to be sure. I didn't find
any precision on this in online documentation so far.
I really suspect that the problem can't come from the sleeping function but
I need to eliminate each
potential source of problem to isolate it.
Thanks for your time.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk