Question

在我的代码中注意到事件的某些时间因素后，我将问题一直归结为我的Windows消息循环。

基本上，除非我做了一些奇怪的事情，否则我会遇到这种情况： -

MSG message;

while (PeekMessage(&message, _applicationWindow.Handle, 0, 0, PM_REMOVE))
{
    int timestamp = timeGetTime();
    bool strange = message.time > timestamp; //strange == true!!!

    TranslateMessage(&message);
    DispatchMessage(&message);
}

我能得出的唯一合理结论是MSG::time使用了不同的计时机制，然后是timeGetTime()，因此可以自由地产生不同的结果。是这种情况还是我错过了一些有趣的东西？

Answer 1

这可能是签名的未签名问题吗？您正在将signed int（时间戳）与无符号DWORD（msg.time）进行比较。

此外，时钟每隔40天就会结束 - 当发生这种情况时，奇怪的情况可能就是真的。

顺便说一句，如果你没有充分的理由使用timeGetTime，你可以在这里使用GetTickCount - 它可以节省你带来的winmm。

下面的代码展示了你应该如何使用时间 - 你永远不应该直接比较时间，因为时钟包装会搞砸。相反，你应该总是从当前时间减去开始时间并查看间隔。

// This is roughly equivalent code, however strange should never be true
// in this code
DWORD timestamp = GetTickCount();
bool strange = (timestamp - msg.time < 0);

Answer 2

我认为期望或依赖于从不同来源返回的时间戳的绝对值之间的任何特定关系是不可取的。一方面，多媒体计时器可具有与系统计时器不同的分辨率。另一方面，多媒体计时器在单独的线程中运行，因此您可能会遇到同步问题。（我不知道每个CPU是否保持自己的独立滴答计数。）此外，如果您正在运行任何类型的时间同步服务，它可能会对您的本地时钟进行自己的调整并影响您看到的时间戳。 / p>

Answer 3

您是否有机会运行AMD双核心？存在这样的问题：由于每个核心具有单独的计时器并且可以以不同的速度运行，因此计时器可以彼此分开。例如，这可以在negative ping times中体现出来。

使用GetTickCount（）测量不同线程中的超时时，我遇到了类似的问题。

安装this driver（IIRC）以解决此问题。

Answer 4

MSG.time基于GetTickCount（），而timeGetTime（）使用多媒体计时器，它完全独立于GetTickCount（）。看到一个计时器在另一个计时器之前“打勾”，我不会感到惊讶。

MSG :: time晚于timeGetTime

4 个答案: