关于timeSetEvent的精确度缺陷分析_备份以防后续使用到时作为参考

原文： https://blogs.msdn.microsoft.com/mediasdkstuff/2009/07/02/why-are-the-multimedia-timer-apis-timesetevent-not-as-accurate-as-i-would-expect/

多媒体定时器的触发原理，通过在硬件层次的中断控制来达到ms毫秒级别的定时精度，由于这个过程需要切换用户态与kernal内核态，大约为10-16ms，

故对于使用timeSetEvent函数来进行定时使用的程序，在不需要十分高精度的情况下，是可以满足大多数的情况的，

但是，对于多媒体，如视频、音频则还有所欠缺；

余下的文章，介绍了操作系统的操作机制，比如影响线程被运行的因素，这里指出来，是包括2个因素，一个为线程优先级，另一个则是线程量度(Thread Quantum)，优先级很好理解，另一个线程量度(Thread Quantum)则是表示一个线程被其他线程挤占处理器前，可以独占处理器的最大时间，比如一个线程可以最多占用100ms的处理器时间，在基于NT的系统上，其他系统可能会略有不同；

然后又举了些例子，表示要使用1ms精度的定时器与周期处理时，若是有其他高优先级(高于多媒体定时器)的线程在运行，那么很可能无法得到实时的定时处理，而是会让该繁忙的线程，用于100ms的时间后才会被操作系统强制去执行其他的任务，若是运气够好，那么下一个任务则有可能是我们编写的线程；

接下来则是指出tiemBeginPeriod/tiemEndPeriod的一些副作用，当用于高精度(短时间)的定时器时，CPU会花费大量的时间用于上下文切换(context switch)，任务调度(scheduling task)等，会有一定的开销需要考虑，在涉及高精度的场景时，这些是必须要考虑到的。

最后，关于timeSetEvent有个无文档的限制：在同一个线程内，仅能定义最多16个定时器，在多个询问中都有出现类似的问题

比较推荐的做法是使用CreateTimerQueue来替换这个，避免这个不成文的限制

http://www.codeguru.com/cpp/w-p/system/timers/article.php/c2837/CWaitableTimer.htm

http://www.cplusplus.com/forum/windows/189665/

https://social.msdn.microsoft.com/Forums/vstudio/en-US/e5eecc1f-2d0c-4fdb-abfb-8c81ebc8f748/problem-with-timesetevent-for-over-16-concurrent-timers?forum=vcgeneral