Sleep/Wait without consuming CPU

后端 未结 1 706
庸人自扰
庸人自扰 2021-01-17 08:13

So I am simulating this smartphone app to Windows. It\'s a game that runs it\'s logic and draw methods at a 1/60 rate. In milliseconds this is 16.6667

相关标签:
1条回答
  • 2021-01-17 08:19

    You need hardware support for this kind of accuracy. A signal that generates an interrupt and trigger code to get the job done. There are two obvious candidates for such a signal in Windows.

    The first one is the VSYNC interrupt, a video device driver implementation detail. It occurs at the monitor refresh rate, usually 60 Hertz for LCD monitors. Just what you are asking for of course, no coincidence. Most programmers use DirectX to implement game graphics, you ask it to use the signal with the D3DPRESENT setting. Otherwise very unclear why you are not using it from the question, but the solution you should pursue.

    The second one is the clock interrupt. That's the one you are complaining about. A big deal on Windows, that's the signal that wakes up the thread scheduler and gets code to run. It is directly responsible for the accuracy of Thread.Sleep(). Code that sleeps cannot start running again until the clock interrupt occurs and the scheduler puts the thread back into the active state. There's no other way to do it, the processor is physically turned off with the HLT instruction, consuming no power, and can only be woken up with an interrupt. By default, the clock interrupt ticks 64 times per second. Once every 15.625 millisecond. It tends to get tinkered with by drivers and whatnot, they often reprogram it to tick at 10 millisecond. Companies that give out free software and have a stake in making their own products look good make it as low as 1 millisecond.

    Which is what you need to do as well if you can't tame DirectX for some reason. Pinvoke timeBeginPeriod(1) to get 1 msec accuracy. Technically you can go as low as 500 microseconds with NtSetTimerResolution() but that's a low as the dial will go. And do keep in mind that you can't sustain such rates consistently, thread scheduling quanta, garbage collection pauses, hard paging faults and obnoxious device drivers that run their code at realtime priority take much longer than that.

    0 讨论(0)
提交回复
热议问题