设计要点与局限

设计要点

• 调度器使用“优先级位图 + 每优先级双向循环链表”
  • 优点：可通过位图快速定位最高优先级就绪任务，典型路径下具备 O(1) 调度查找能力。
  • 优点：同优先级任务再通过链表组织，便于实现时间片轮转和主动让出。
• 通用内核与移植层分离
  • 优点：调度、任务、IPC、定时器等逻辑保持平台无关，方便后续移植到不同 Cortex-M 或其它架构。
  • 优点：上下文切换、中断控制等强平台相关逻辑集中在 portable.h 与 libcpu/ 中，边界清晰。
• 任务对象和大多数内核对象由用户静态提供
  • 优点：不依赖动态内存分配，行为更可预期，更适合资源受限 MCU。
  • 优点：避免了动态分配失败、堆碎片等额外问题。
• 软件定时器与任务延时共用统一 tick 驱动框架
  • 优点：实现简单，超时语义统一，便于维护。
  • 优点：任务延时、IPC 超时、普通软件定时器都建立在同一套时间基上。
• IPC 阻塞队列支持 FIFO 与按优先级排队两种策略
  • 优点：应用可以根据公平性或实时性需求选择不同阻塞排序方式。
• 互斥锁支持递归持有与优先级继承
  • 优点：适合嵌套调用链中重复进入同一临界资源保护区。
  • 优点：在常见优先级反转场景下能提升系统实时性。

局限与注意事项

• 互斥锁的优先级继承属于惰性继承
  • 局限：只有在高优先级任务真正因获取锁失败而阻塞时，owner 才会被提升优先级。
  • 局限：当前实现没有维护“等待任务优先级集合”的精细恢复机制，因此在多锁或复杂嵌套场景下，任务当前优先级可能出现偏高持续一段时间的现象。
• 任务优先级位图当前基于 32 位整数
  • 局限：当前最大任务优先级数固定为 YR_TASK_MAX_PRIORITY == 32，继续扩展时需要同步调整位图实现。
• 软件定时器基于系统 tick 驱动
  • 局限：时间精度受 YR_TICK_RATE_HZ 限制，不适合高精度硬实时定时需求。
  • 局限：tick 越高，时基中断开销越大；tick 越低，延时粒度越粗。
• 软件定时器回调直接在 tick 更新相关路径中执行
  • 局限：回调逻辑不宜过重，否则会拉长中断后处理或调度相关路径时间。
• 队列采用“拷贝式收发”
  • 优点：数据所有权清晰，不要求发送方和接收方长期共享同一块对象。
  • 局限：当消息体较大或频繁传输时，拷贝开销会变得明显。
• 当前对象删除语义偏保守
  • 优点：任务删除先转 TERMINATED 再由 idle 回收，更安全，便于后续扩展到动态内存场景。
  • 局限：删除不是“立即彻底销毁”，文档和应用设计上需要接受这种延迟回收语义。
• 当前 API 对上下文要求较严格
  • 局限：任务态、ISR 态可调用函数并不完全重合，使用者需要明确区分普通版本与 _from_isr 版本。
• 当前内核强调“小而清晰”
  • 优点：实现容易理解、适合教学与裁剪。
  • 局限：暂未覆盖事件标志组、动态任务、SMP、更复杂的电源管理等高级特性。