好几年没发原创帖了，说来惭愧，今天转存一下笔记，浅谈一下自己对windows的apc机制的一点理解。

在windows里如果线程A的apc要交付，可能在线程A的上下文直接调用KiDeliverApc交付;也可能对线程A所在processor发一个APC_LEVEL的ipi(可能是self ipi，也可能是其它processor对当前processor发出的ipi，这里以发self ipi的情形加以说明)。第二种情况纯属一厢情愿，因为当这个ipi对应的isr执行时，此时的processor上的线程可能就不是线程A，而有可能是线程B(因为发这个APC_LEVEL ipi前的irql(从wrk代码中看到此时的irql为SYNC_LEVEL)可能低于时钟中断对应的IRQL，这就很可能会因为线程A的时限用完导致在发出APC_LEVEL的ipi之后到这个ipi的isr执行时之间当前processor会有一个pending状态的DISPATCH_LEVEL的中断，当前processor的IRQL降低到DISPATCH_LEVEL以下时这个DISPATCH_LEVEL中断执行，导致调度器选择线程B在当前processor上执行，然后APC_LEVEL中断到来时处于线程B的上下文)，在这里好像会造成“本来是让线程A的apc交付，结果当前processor的APC_LEVEL中断却让线程B的apc交付(如果线程B有apc待交付且满足交付条件)，而这个APC_LEVEL的中断造成线程A的apc得不到交付，但是线程A的KernelApcPending一直为TRUE”。想了很久，最终决定搜索wrk代码，忽然发现SwapContext里会检测新线程的KernelApcPending，返回后相关函数判断KernelApcPending为TRUE时直接在新线程上下文调用KiDeliverApc交付新线程的apc。至此迷题解开，即当线程A在将来某个时机被调度执行，它的apc肯定有机会被交付，虽然错失了此前本想在APC_LEVEL中断执行时交付的机会。终于明白为什么线程切换回时会交付apc，这也确实能说明apc只跟特定线程相关。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！