Windows内部原理（go to Quantum End section）指出了Windows的早期版本曾经如何不公平地惩罚线程，但是自Vista以来，它现在对从时钟间隔中途开始或用于中断处理的线程的计费时间更长。
我熟悉ReactOS内核和Windows Research Kernel源代码。 KiQuantumEnd函数由KiDispatchinterrupt调用，最有可能由软件中断调用，该中断在量子到期时被请求，即，线程以6个量子单元开始，每个时钟中断减去3个，大于或等于0的时钟中断ISR（KiUpdateRunTime）请求自IPI。 KiQuantumEnd仅记录在ReactOS上，并且由于ReactOS表现出XP行为，因此它不会检查不公平的惩罚，而只是调度和调度新线程。
很明显，在Windows Vista及更高版本上，它的实现方式有所不同，但WRK并未公开该功能，因此我无法对其进行研究。我希望我知道它实际上如何实现Windows内部说明的公平时间分片。
我唯一想到的方法是在所有从中断对象调用ISR的未链接ISR条目中注册的通用中断处理程序（未记录的KiInterruptDispatch）可能会执行RDTSC如果嵌套级别为1，则增加嵌套级别，并在KiInterruptDispatch返回时在中断结束时降低嵌套级别，如果等于1，则可以执行另一个RDTSC并存储两者之间的差在线程对象的成员中（通过这种方式，外部中断将保持计时）。当然，这不会算作SMI，它确实与Windows内部部分的措辞相抵触，该措辞暗示记录了线程所消耗的循环总数，但听起来比我建议的方法要实用得多。在线程对象中记录丢失的周期数量，而不是记录给线程充电的周期数量是很有意义的，我想不出任何实用的方式来跟踪它。
对于在中间时钟间隔内调度线程的情况，我能想到的唯一方法是调度代码采用RDTSC并将其存储在单独的线程成员中，然后KiQuantumEnd做一个RDTSC，减去计划时记录的原始值，然后减去记录丢失周期的其他成员，然后与目标周期数进行比较。
KTHREAD结构中有一些有趣的字段，例如'CycleTime'和'CurrentRunTime'。
如果有人知道任何其他实现或实际实现，请告诉我。