抢占式 vs 协作式调度模型
调度模型不是“实现方式差异”，而是操作系统对“时间控制权归属”的根本定义。 抢占式与协作式，本质上是在回答同一个问题：系统是否允许任务自主控制CPU。
一、调度模型的本质：CPU控制权归属问题
在所有操作系统设计中，调度模型的核心不是“如何切换任务”， 而是“谁决定切换任务”。 很多关于内核复杂度、实时性和任务设计风格的讨论，最终都会回到这个根问题。
如果CPU控制权属于内核 → 抢占式模型 如果CPU控制权部分属于任务 → 协作式模型 因此，yield()、阻塞API以及中断返回点，都是控制权交接的重要时刻。
二、抢占式调度（Preemptive Scheduling）
抢占式调度是RTOS的主流模型，其核心特征是：系统拥有绝对调度权。 任何时候，只要条件满足，高优先级任务可以中断当前任务执行。 这也是高优先级控制任务能够压过后台日志任务的根本原因。
其关键特征不是“更快切换”，而是“随时可切换”。 新手常把抢占理解成“更暴力的轮询”，其实它的重点是把控制权从任务手里收回到内核手里。
时间控制权
完全由内核掌控，任务无法阻止切换发生。这样关键任务的响应时间才有机会被证明。
实时性优势
可保证高优先级任务在最短时间内获得CPU。对硬实时控制来说，这是最重要的结构优势。
系统复杂度
需要处理优先级反转与并发同步问题。内核与应用都必须认真对待共享资源设计。
确定性
具有更强的最坏情况时间上界控制能力。只要路径可分析，就能建立更可靠的时序预算。
三、协作式调度（Cooperative Scheduling）
协作式调度将部分调度责任交给任务自身。 任务必须主动释放CPU，系统才会切换。 如果某个任务忘记让出CPU，其他任务即使更重要也只能等待。
其本质是“任务自律模型”，而不是“系统强控制模型”。 协作式在结构简单的状态机系统中仍有价值，但前提是团队能够严格约束任务写法。
执行控制
任务主动让出CPU，内核不强制中断。控制权看似简单，但风险也随之下放给应用层。
系统复杂度
实现简单，但依赖任务正确设计。代码规范一旦松动，时序问题很快会积累。
风险结构
单任务阻塞会导致整个系统停滞。尤其是长循环、等待外设或忙等代码最危险。
实时性限制
无法保证严格时间上界。只要任务让出CPU的时机不可证明，系统就难以满足硬实时要求。
四、本质差异：系统控制模型不同
两者的区别不在“性能”，而在“系统是否允许不可控执行窗口存在”。 协作式的主要风险并不是慢，而是不可证明；抢占式的主要成本也不是快，而是更复杂。
因此它们不是优化关系，而是结构级选择。 只有当你先明确业务是否需要严格时间边界，后续的模型选择才会自然清晰。
五、对实时系统的影响
在RTOS中，调度模型直接影响系统是否具备“时间可证明性”。
抢占式优势
适用于硬实时系统（工业控制 / 飞控 / 医疗系统）。它更容易把关键任务的响应时间压到明确上界内。
协作式优势
适用于轻量嵌入式或非关键实时任务。在任务数量少、逻辑简单时，它能降低实现复杂度。
风险对比
抢占式风险在内核复杂度；协作式风险在任务失控。二者都不是零成本，只是风险分布位置不同。
确定性
抢占式提供可计算上界，协作式无法严格保证。实时系统最终更在意这一点，而不是表面上的实现轻重。
六、结论：不是选择机制，而是选择系统类型
在HRTOS体系中，默认采用抢占式调度， 因为实时系统的核心不是效率，而是“时间约束的可证明性”。 当然，在资源极小、任务关系简单的产品里，协作式仍可作为过渡方案，但一旦引入严格截止时间，通常就要转向抢占式。
七、调度模型在RTOS体系中的位置
调度模型不是独立概念，而是RTOS执行链路中的核心控制层。 它连接任务创建、上下文切换与CPU执行之间的关系。 理解这层位置后，就更容易看懂为什么某些系统会在中断返回时立即判断是否需要切换任务。
调度模型决定“何时切换”，上下文切换决定“如何切换”。 把这两者区分开，是理解RTOS执行链最重要的基本功之一。