I'm having, sometime, trouble with a rare heisenbug (rare but appearing several times a week). I described it there: http://stackoverflow.com/questions/17918548/can-windows-totally-stop-a-threa... 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. Litterally: static const auto TIME_SCHEDULED_TASKS_SPAWN_FREQUENCY = microseconds(250); while( !m_task_scheduler.is_exiting() ) // check if the application should exit { m_clock_scheduler.spawn_realtime_tasks(); // here we spawn tasks if it's time this_thread::sleep_for( TIME_SCHEDULED_TASKS_SPAWN_FREQUENCY ); } m_clock_scheduler.clear_tasks(); m_root_task.wait_for_all(); 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 boost::this_thread::sleep_for(). 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. Joel Lamotte