我遇到了一个奇怪的行为，等待定时器。 如果我用一秒的时间创build它，然后在第一次触发之后，其后续的触发似乎与几毫秒的数值“alignment”，这与第一次触发明显不同。
这是火时间的示例（小时：分钟：秒。毫秒）：
18:06:25.753 <-- here 753 18:06:26.238 <-- here and later 238 18:06:27.238 18:06:28.238 18:06:29.238 如果我重新运行程序，第一次触发的毫秒值是不同的，但后续事件再次发生在238值。
这里是我使用的testing代码：
int _tmain(int argc, _TCHAR* argv[]) { HANDLE hTimer = CreateWaitableTimer(NULL, FALSE, NULL); LARGE_INTEGER dueTime; dueTime.QuadPart = 0; SetWaitableTimer(hTimer, &dueTime, 1000, NULL, NULL, FALSE); for (int i=0; i<10; i++) { WaitForSingleObject(hTimer, INFINITE); SYSTEMTIME st; GetLocalTime(&st); printf("%02d:%02d:%02d.%03d\n", st.wHour, st.wMinute, st.wSecond, st.wMilliseconds); } return 0; }
我在Windows 7和Windows Server 2008 R2中看到此问题，但在Windows XP / Server 2003中看不到此问题。
任何人都知道这是为什 我可以想象，可以通过一些系统优化来减less定时器中断和/或上下文切换。 但是我无法在任何地方find它。 这是意想不到的，可能导致问题。
dueTime.QuadPart = 0;
你打算用这个说法呢？
该文件说：“ 正值表示绝对时间。 ”和“ 负值表示相对时间 ”。 零从未指定dueTime的可能值。
相反，你应该通过指定找到一个合理的开始时间
第一个事件发生的相对时间。
dueTime.QuadPart = -1000000; // 100 ns units, first event at 100 ms from now
绝对的时间
FILETIME FileTime; LARGE_INTEGER dueTime; GetSystemTimeAsFileTime(&FileTime); CopyMemory(&dueTime,&FileTime,sizeof(FILETIME)); dueTime.QuadPart += 1000000; // 100 ns units, first event at 100 ms from FileTime
注意：等待定时器允许以100 ns为单位指定到期时间。 这并不意味着他们可以以这种精确度触发。 准确度由系统时间粒度决定。 有关系统时间粒度的更多细节可以在这个答案中找到。