Run codes for only 60 times each second

I'm creating a directx application that relies on the system time (because it must be accurate), and I need to run lines of code for 60 times each second in the backgrou开发者_StackOverflownd (in a thread created by boost::thread). that's equal to 60 FPS (frame per second), but without depending on the main application frame rate.

//.................
void frameThread()
{
    // I want to run codes inside this loop for *exactly* 60 times in a second.
    // In other words, every 16.67 (1000/60) milliseconds
    for(;;)
    {
      DoWork();
      //.........
    }
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
   initialize();
   //.....stuffs
   boost::thread framethread(frameThread);
   //......
}

Is there a way to do this?

Any kind of help would be appreciated :)

Since 60 Hz is a common monitor refresh rate, it sounds like you want to enable V-Sync, instead of messing around with timers and sleeps.

You mentioned you're using DirectX - If you're using DirectX 9, specify D3DPRESENT_INTERVAL_ONE when creating the device, and the application will synchronize to the monitor refresh rate. Usually this is 60 Hz - but it could also in theory be anything, such as 50Hz, 85Hz or 120Hz. You get a very nice tear-free display though - if you don't use V-sync, you'll likely get tearing artefacts when scrolling.

This raises the problem: how do you make the game progress at the same speed if the framerate could vary so much? The answer is simple - use a high resolution timer (like QueryPerformanceCounter on Windows), and measure the time between each frame. Then you need to base any motion or movement off this 'delta time' value. This is a good thing to do anyway, even with a fixed framerate - it prevents your game suddenly running in slow motion if the computer is slow and the player only gets 20fps.

Here's an example of moving an object horizontally at 100 pixels per second, regardless of the framerate:

object.x += 100.0f * delta_time; // same speed no matter the framerate

This IMO is a much better way of doing this, especially given it's tearing-free, framerate-independent, and synchronises with the user's monitor, not some arbitrary framerate you set yourself.

Get the system time before DoWork(), add to it a 1/60 of a second and store it for later use. After DoWork() (which must run for less than a 1/60 of a second) you have to sleep until the system time is equal to the previously stored time. That should do the trick.

Use waitable timer as a synchronization object.

HANDLE hWaitTimer;

void frameThread()
{
    while ( WaitForSingleObject( hWaitTimer, INFINITE ) == WAIT_OBJECT_0 )
    {
      // reactivate timer
      LARGE_INTEGER due_time = {0};
      due_time.LowPart = 10000/60; // in 100 nanosecond intervals
      ::SetWaitableTimer( hWaitTimer,  &due_time, 0, NULL, NULL, FALSE );

      DoWork();
      //.........
    }
}

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
    hWaitTimer = ::CreateWaitableTimer( NULL, FALSE, NULL );
    LARGE_INTEGER due_time = {0};
    due_time.LowPart = 10000/60; // in 100 nanosecond intervals
    ::SetWaitableTimer( hWaitTimer,  &due_time, 0, NULL, NULL, FALSE );

    // create trhead etc.


    // before exit
    CloseHandle( hWaitTimer );
}

What do you mean by "accurate" ? Windows isn't an RTOS so there is no way you can get real accuracy out of it. You can get pretty close, but you can't guarantee that your thread will be scheduled when you want it at all.

Anyway, I'd go for a waitable timer, a thread pool and RegisterWaitForSingleObject.

If you really need high precision, use platform-specific multimedia timer, see timeSetEvent function, http://msdn.microsoft.com/en-us/library/aa448195.aspx. Use TIME_PERIODIC with TIME_CALLBACK_FUNCTION flags, uResolution=0. In any case DirectX is not portable.

I don't think that you can get required precision using cross-platform Boost thread.

If you are 100% that you will not run longer that 1/60s then solution would be to use semaphore and separate timer that ticks every 1/60s.

In timer thread you semaphore.V() and in your worker thread you semaphore.P().

Windows has native semaphores.

If your worker thread can take longer than 1/60 then you should compensate for that via some kind of "worker_lock" instance variable. Never lock in timer thread, it must be as fast as possible. Also raise the priority of timer receiving thread.