咱们来拆解下背后的核心原因，把这个场景捋清楚：

• 核心资源已被高优先级线程完全占满
  四核处理器上4个高优先级线程并行运行，意味着每个物理核心都被一个高优先级线程牢牢占住了。Windows的调度器遵循"优先级抢占"原则——高优先级线程会优先获得CPU时间，只有当这些高优先级线程主动放弃CPU（比如进入睡眠状态、等待IO完成），低优先级的目标程序才有机会被调度执行。在这种满负载的高优先级线程场景下，目标程序大概率会被"饿死"，连基本的执行机会都很少，更别说每隔X/2毫秒就跑一次计数了。

• 上下文切换的时间成本限制了调度间隔
  题目里定义X是线程上下文切换的最短时间。就算某个高优先级线程临时让出了CPU，调度器要把CPU控制权切换给目标程序，本身就需要至少X毫秒的开销。这意味着目标程序两次被调度执行的间隔，至少是X毫秒（实际可能更长，因为还要看高优先级线程的运行状态）。而你的程序想要每隔X/2毫秒就更新一次计数，这个频率比系统能提供的最小调度间隔还高——等目标程序终于能运行的时候，已经过去了好几个X/2的时间段，根本没法实时、准确地统计流逝的次数。

• 系统定时器精度也达不到这么高的要求
  退一万步说，就算调度器能给目标程序分配时间，Windows默认的系统定时器精度大概在15.6毫秒左右（就算启用高精度定时器，也受硬件和调度器的限制）。X作为上下文切换的最短时间，通常也会在几毫秒级别，X/2就更小了，这种级别的定时精度，普通应用程序根本没法稳定实现，计数自然也就不可能准确。

内容的提问来源于stack exchange，提问作者Jebakumar