可以通过系统 API timeBeginPeriod来修改系统定时器精度到 1ms（它内部使用了没有给出文档的NtSetTimerResolution，这个 API 可以修改到 0.5ms）。不需要的时候使用timeEndPeriod还原。
修改系统定时器精度有副作用。它会增加上下文切换的开销，增加耗电量，降低系统整体性能。然而，很多程序都不得不这么做，因为没有其它方式能获得更高的定时器精度。比如基于 WPF 的程序（包括 Visual Studio）、使用 Chromium 内核的应用（Chrome、QQ）、多媒体播放器、游戏等等很多程序都会在一定时间内把系统定时器精度修改到 1ms。（查看方法见后面）
所以实际上这个副作用在桌面环境已经成为常态。而且从 Windows 8 开始，这个副作用减弱了。
在 1ms 的系统定时器精度前提下，可以使用三种方式实现阻塞等待：
（1）Thread.Sleep
（2）WaitHandle.WaitOne
（3）Socket.Poll
另外，多媒体定时器timeSetEvent也使用了阻塞的方式。
（1）Thread.Sleep
它的参数使用毫秒单位，所以最多只能精确到 1ms。不过事实上很不稳定，Thread.Sleep(1)会在 1ms 与 2ms 两种状态间跳动，也就是可能会产生 +1ms 多的误差。
实测发现，没有任务负载的情况下（纯粹循环调用Sleep(1)），阻塞时长稳定在 2ms；而有任务负载时，则至少会阻塞 1ms。这和其它两种阻塞方式不同，详见后文。
如果需要修正这个误差，可以在阻塞 n 毫秒时，使用Sleep(n-1)，并通过Stopwatch计时，剩余等待时间用Sleep(0)、Thread.Yield或自旋来补充。
Sleep(0)会出让剩余的 CPU 时间片给优先级相同的线程，而Thread.Yield是出让剩余的 CPU 时间片给运行在同一核心上的线程。在出让的时间片结束后，其会被重新调度。一般情况下，整个过程可以在 1ms 之内完成。
Thread.Sleep(0)和Thread.Yield在 CPU 高负载情况下非常不稳定，实测可能会阻塞高达 6ms 时间，所以可能会产生更多的误差。因此误差修正最好通过自旋方式实现。
（2）WaitHandle.WaitOne
WaitHandle.WaitOne与Thread.Sleep类似，参数也是毫秒单位。
不同之处是，没有任务负载的情况下（纯粹循环调用WaitOne(1)），阻塞时长稳定在 1.5ms；而有任务负载时，则可能仅阻塞近乎于 0 的时间（猜测是它仅阻塞到当前时间片结束，尚未找到具体的文档说明）。所以它阻塞的时长范围是 0 到 2ms 多。
