概述
HRTOS 任务生命周期围绕任务控制信息、任务执行现场及调度状态展开。 任务创建后，系统需要保存其入口与运行所需的信息， 并在调度条件满足时安排任务执行。
任务管理与等待机制承担不同职责：Task 模块关注任务的管理与执行状态； Wait 模块处理任务因时间、事件或资源条件而产生的等待行为。 两者需要协同工作，但不应简单地视为同一套状态定义。
生命周期模型
下图用于表达任务管理中的主要阶段，以及运行控制和删除回收两条路径。 它是概念流程图，不代表所有任务状态都只能沿单一路径转换。
任务创建
任务通过 os_task_create() 请求创建。
按接口约定，创建过程可能涉及任务 ID 检查、参数校验、
优先级配置以及任务执行现场的初始化。
实际检查项与资源分配方式以当前版本的接口实现为准。
os_task_create(
addr,
id,
pr,
sd
);创建成功后，系统需要保留任务入口、执行现场及调度所需的信息， 使该任务能够在满足调度条件时运行。 调用方应检查创建结果，并确保传入参数符合 API 的定义。
运行与控制
创建完成并满足运行条件的任务可以参与调度。 调度器依据当前的任务状态、优先级规则和调度模式决定后续执行实体。 任务 ID 用于标识任务，不应与任务优先级混为一谈。
普通任务：
ID 0 ~ OS_PROCESS_MAX - 1
高速任务：
ID OS_PROCESS_MAX
~ OS_PROCESS_MAX + 1上述编号范围依赖相关配置。任务运行过程中，应用可以按照 API 约定 请求暂停、恢复或主动让出执行权。接口调用是否立即触发切换， 还取决于当前执行上下文与调度规则。
任务删除与资源回收
HRTOS 的任务删除设计涉及删除请求、执行控制和资源清理。 对于采用延迟回收机制的实现，发出删除请求并不意味着 所有相关资源会在该调用返回前立即释放。
发出删除请求
通过 os_task_delete(id) 请求删除目标任务。
调用是否成功以及目标任务的允许范围，应检查实际 API 约定。
记录待处理状态
若当前实现使用删除请求标志或事件，系统会记录待处理请求， 使后续执行路径能够识别需要清理的任务。
进入安全清理路径
系统在符合实现约束的时机处理删除任务， 避免在仍依赖当前执行现场时过早释放相关资源。
完成资源回收
按照当前内核的清理逻辑释放或重置相应资源， 并更新任务管理信息。
os_task_delete(id)
|
v
记录删除请求
|
v
由内核在安全时机处理
|
v
任务清理路径
|
v
资源回收与管理信息更新OS_TASK_EVENT、OS_EVENT_DELETE_REQ
或 os_task_cleanup() 当作正式实现名称。
概念流程不能替代对实际内核代码的核对。
任务状态查询
任务状态查询接口可用于 Shell、调试程序和运行状态监控。 它帮助调用方了解任务当前或最近的执行情况， 但查询结果的具体语义取决于接口定义。
os_task_get_state(id)如果当前版本使用数字编码表示任务状态， 应以对应头文件或 API 文档中的枚举定义为准。 特别需要区分“当前运行任务”“就绪任务”“挂起任务” 与“最近一次切出的任务”等不同含义。
任务生命周期相关接口
以下接口覆盖常见的任务控制操作。具体参数、返回值、 可调用上下文及调用限制应以当前版本的 API 定义为准。
os_task_suspend(id)
请求暂停或挂起指定任务。
os_task_resume(id)
请求恢复符合条件的任务。
os_task_delete(id)
请求删除指定任务。
os_task_exit()
请求当前任务退出；具体退出及回收语义以实现为准。
os_task_yield()
主动让出执行机会；实际调度效果由调度策略决定。
os_task_self()
获取当前任务标识，具体返回类型以 API 定义为准。
设计要点
- 任务标识、任务状态与优先级承担不同职责，应分别理解。
- 任务控制接口需要遵循内核规定的调用上下文与状态约束。
- 任务执行现场与任务资源的生命周期相关，但并不等同于任务状态。
- 如果采用延迟删除与回收机制，应区分删除请求和实际回收完成。
- 等待机制与任务管理相互协作，但不应在文档中混淆两者的状态定义。
- 长时间运行稳定性依赖正确的状态转换、现场管理和资源回收。