2、实时内核核心指标：任务切换延迟、中断响应时间、抢占机制

各位同学，咱们今天聊点实在的。选实时内核，说白了就是看三个硬指标：任务切换延迟、中断响应时间、还有抢占机制。这三个东西，我当年刚入行时也搞混过，后来在几个项目里吃了亏，才算真正摸透了。

2.1 任务切换延迟——别小看这几十微秒

任务切换延迟，指的是内核从一个任务切换到另一个任务所花的时间。嗯，这里要注意，不是你想切就能立刻切的。内核得先保存当前任务的上下文，再恢复新任务的上下文，这中间还有调度器的决策时间。

我习惯把任务切换延迟拆成两部分：

• 决定时间：调度器选下一个任务要多久
• 切换时间：保存/恢复寄存器、堆栈指针这些

我在项目中遇到过一件事。有个工业控制项目，要求20kHz的控制循环，也就是50微秒一个周期。我一开始用了某个通用RTOS，任务切换延迟平均35微秒。你想想看，一个周期才50微秒，切换就占了35微秒，剩下的15微秒能干啥？啥也干不了。后来换了个轻量级内核，切换延迟压到5微秒以内，问题才解决。

不同内核的切换延迟差异很大。我整理了个对比表，供你参考：

内核类型	典型切换延迟	抖动范围	适用场景
FreeRTOS	5-15 µs	±2 µs	软实时、IoT
RT-Thread	3-10 µs	±1 µs	消费电子、工控
VxWorks	1-5 µs	±0.5 µs	航空航天、硬实时
μC/OS-III	4-12 µs	±1.5 µs	医疗、汽车

2.2 中断响应时间——实时系统的生命线

中断响应时间，就是从硬件中断信号触发，到中断服务程序（ISR）第一条指令开始执行的时间。说白了，就是系统对外部事件的反应速度。

为什么会这么重要？你想想看，一个紧急刹车信号来了，系统得在几微秒内响应。如果中断响应时间太长，后果不堪设想。

中断响应时间由三部分组成：

1. 硬件延迟：CPU响应中断的固有时间，一般固定
2. 内核关中断时间：内核为了保护临界区，会暂时关闭中断。这是最大的变数
3. 中断向量查找：找到对应的ISR入口地址

我曾经在一个项目中，发现中断响应时间忽大忽小。查了三天，最后发现是某个驱动在临界区里关了中断长达200微秒。嗯，这就是典型的"关中断时间过长"问题。

不同内核的中断响应时间对比：

内核	最大关中断时间	中断响应时间	备注
FreeRTOS	可配置，通常<20 µs	5-30 µs	关中断时间取决于配置
RT-Thread	通常<15 µs	3-20 µs	支持中断嵌套
VxWorks	<5 µs	1-10 µs	硬实时标杆
μC/OS-III	通常<10 µs	3-15 µs	关中断时间可控

2.3 抢占机制——谁说了算？

抢占机制，说白了就是高优先级任务能不能打断低优先级任务。这是实时内核的核心能力。

我习惯把抢占机制分成三种：

• 非抢占式：任务主动让出CPU，否则一直跑。适合简单系统，但实时性差
• 可抢占式：高优先级任务可以打断低优先级任务。这是主流
• 时间片轮转：每个任务分一个时间片，轮流跑。适合软实时

我个人习惯用可抢占式内核。但要注意，抢占不是免费的。每次抢占都意味着一次任务切换，也就意味着额外的延迟。

这里有个常见的坑：优先级反转。低优先级任务占着资源不放，高优先级任务干等着。我曾经在一个项目中，因为优先级反转，导致一个紧急任务延迟了500微秒。解决办法是用优先级继承协议。

不同内核的抢占机制对比：

内核	抢占类型	抢占点	优先级反转处理
FreeRTOS	可抢占	系统调用返回时	无内置支持
RT-Thread	可抢占+时间片	系统调用返回、中断退出	优先级继承
VxWorks	完全可抢占	任意点	优先级继承+天花板
μC/OS-III	可抢占	系统调用返回时	优先级继承

最后说一句，这三个指标是相互关联的。任务切换延迟短，不代表中断响应快。抢占机制好，也不代表切换延迟低。选型时，得根据你的应用场景，找到平衡点。

我个人习惯先确定中断响应时间的要求，再选抢占机制，最后看任务切换延迟能不能接受。这个顺序，我在十几个项目里验证过，挺靠谱的。