• 12
• 12
• 9
• 10
• 13

# Inaccuracy of windows thread waits

This topic is 3498 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Is anyone aware of a method to get greater then the 15 millisecond or so accuracy used by the windows thread wait functions( such as Sleep(), WaitForSingleObject()SignalObjectAndWait())? MSDN claims timeBeginPeriod() should increase the accuracy, but even setting it to 1 does not help. I really need far greater accuracy for what I am doing and am rather amazed at how inaccurate these functions are.. Thanks

##### Share on other sites
You can call timeBeginPeriod (and timeEndPeriod) to lower the slicing time to roughly 1ms. Out-of-the-box many PCs are configured to slice at 16ms intervals today (in the past it was 10ms!).

Note that Sleep() does not make any timing guarantees other than your thread will be serviced again sometime 'later'.

To do better than that you would have to hook into a hardware timer and I don't think there's an easy way to do that.

##### Share on other sites
Why do you need lots of accuracy?

If you only need to wait for a small amount of time, then a spin-lock (possibly with a Sleep(0) call) may be appropriate.

##### Share on other sites
Quote:
 Original post by AndyPandyV2 I really need far greater accuracy for what I am doing and am rather amazed at how inaccurate these functions are.
The OS is not designed for hard Real-Time computing requirements.

The OS works on scheduled time slices, and yielding the rest of your time slice sticks you at the back of the queue within your priority level. You have no guarantees about when (if ever) the OS will return to you.

What exactly are you trying to do that requires being woken up at more frequent intervals?

There may be other options available, such as Sleep(0) mentioned above so you wait until others in the slice have all yielded their time, using a callback from some other system or driver, operating at the kernel or device driver level, or otherwise digging your application into the OS internals. Deciding the best course of action depends on your eventual goal.

##### Share on other sites
I was hoping to use these wait functions so that the primary threads of the game could surrender any leftover time in the frame to other secondary threads. And while setting timeBeginPeriod seems to slightly increase the accuracy, there are still instances where it takes up to 45+ milliseconds for the Wait to return which is causing very ugly stuttering. I guess I'll just have to waste those extra cycles spinning and doing nothing...

##### Share on other sites
Quote:
 Original post by AndyPandyV2I was hoping to use these wait functions so that the primary threads of the game could surrender any leftover time in the frame to other secondary threads. And while setting timeBeginPeriod seems to slightly increase the accuracy, there are still instances where it takes up to 45+ milliseconds for the Wait to return which is causing very ugly stuttering. I guess I'll just have to waste those extra cycles spinning and doing nothing...
If other games can manage without going to this trouble, then your game should be able to as well. If you're getting inconsistencies in your frame rate then you're probably hitting the disk during play, even if it's just paging memory.
Spinning until the desired time elapses probably wont help. Hogging the CPU can make your app less smooth, as the task scheduler compensates somewhat I believe.
Any chance you can profile your code?

##### Share on other sites
You may find that instead of sleeping, blocking waiting for a critical section / mutex / event will work better.

##### Share on other sites
I've profiled it, it is the Wait calls, they sometimes take 10x longer then they should. It makes sense now that I know about the OS scheduling rather lengthy time slices for different threads, likely there just aren't any slices available when the wait runs out so it has to wait until the next round of slices. I was assuming the OS would return control when the time was up but it is obviously not consistent so I'll just have to rework it to function differently.

##### Share on other sites
You could try.

http://msdn.microsoft.com/en-us/library/ms686277(VS.85).aspx

##### Share on other sites
Quote:
 Original post by AndyPandyV2I was hoping to use these wait functions so that the primary threads of the game could surrender any leftover time in the frame to other secondary threads.

Wrong reason. Concurrency is all about *not* waiting for anything, but simply going on and doing useful work.

If you need to wait in this manner, then cooperative threads or single-threaded approach will be much better.

Multi-threaded programming is annoying because of such details. One solution is to simply not wait:
while (true) {  if (currentTime < nextFrameTime) {    doSomethingUseful();  } else {    renderFrame();  }};
The other, when using worker threads:
while (scheduler->running() {  Task * task = NULL;  if (this->isRenderThread()) {    task = scheduler->getRenderTask();  } else {    task = scheduler->getNextTask();  }  if (task) {    task->run();  } else {    scheduler->waitForTask();  }}
You can then just spawn a number of these workers, and they'll wait for work to come in. Rendering however will always be performed in same, main thread. Obviously, more generic approaches exist for this.

Quote:

This is generally wrong solution to the problem. There are uses for priorities, but this isn't one of them.

Quote:
 I was assuming the OS would return control when the time was up

Unless the OS and hardware you're running on comes with a large fancy certificate saying "Real-Time" and costs a fortune, you will never have such guarantees.

Quote:
 I really need far greater accuracy for what I am doing and am rather amazed at how inaccurate these functions are

For concurrency, you don't need a timer at all, at least not for this. OS times the slices quite well. Even for cooperative threads.