执行流模型 Execution Flow.
执行流描述处理器在任务代码、中断处理程序和内核控制路径之间的运行过程。 对实时操作系统而言，理解执行流不仅需要知道代码如何执行， 还需要明确执行路径的切换条件、时间开销与分析边界。
什么是执行流？
先定义分析对象，再讨论控制路径和执行时间。
从明确入口，到明确出口
执行流是处理器从某个明确的起始事件或执行位置出发， 沿实际控制路径运行，直到到达指定结束位置的过程。
在 HRTOS 中，执行流可能涉及任务运行、内核服务、中断处理、 调度判断以及上下文保存与恢复。不同执行路径的组成并不完全相同， 因此时间分析必须先明确分析对象。
执行流的基本结构
一个用于分析的抽象模型：事件进入、内核判断、执行选择，最终继续运行或转移控制流。
从事件到处理器执行路径
一条典型的任务执行路径可以抽象为以下过程。 这是一种分析视图，而不是要求所有任务都严格经过每一个阶段。
执行流从哪里开始？
不同触发来源会进入不同的处理路径，不应将它们统一视为外部中断。
四类常见触发来源
执行路径可以由多种事件或控制操作引起，不能简单地认为每个任务都由外部中断直接触发。
- 外部或外设中断： 处理器响应中断请求后进入相应中断服务路径。
- 系统 Tick 与超时： 系统时基推进后，内核可能处理到期事件并改变相关任务状态。
- 任务主动调用内核服务： 例如任务延时、等待消息、释放资源或发送消息。
- 任务状态变化： 某个任务具备运行条件后，可能进入就绪集合，等待调度器选择。
调度器如何决定下一步？
调度是一项控制决策，而不是任务状态变化的同义词。
调度结果取决于实际内核规则
调度器根据任务就绪情况和内核规定的调度策略，决定接下来应执行哪个任务， 或判断当前执行对象是否可以继续运行。
- 任务优先级及同优先级任务的处理规则。
- 当前任务是否仍然具备运行条件。
- 时间片、延时到期和其他调度触发条件。
- 中断返回路径及内核执行环境对调度时机的影响。
调度是按照具体算法执行的控制决策，并不天然等同于一个通用的约束优化问题。 实时性是否满足，还需要进一步分析执行时间、干扰条件和任务截止时间。
任务状态与执行资格
任务状态描述其运行条件，调度决策则决定处理器接下来执行什么。
从任务状态理解执行条件
任务状态决定任务当前是否具备被调度执行的条件。 就绪状态、运行状态和阻塞状态之间的转换，会改变调度器可选择的任务集合。
- Ready：任务具备运行条件，等待获得处理器。
- Running：任务当前正在执行。
- Blocked：任务正在等待时间、消息或其他事件。
上述名称是常见的任务状态抽象。具体状态定义、转换条件和特殊状态， 应以 HRTOS 对应版本的实现及文档为准。
任务状态变化和调度决策密切相关，但二者并不相同： 状态描述任务的运行资格，调度决策确定执行对象。
中断介入与路径恢复
中断会引入新的执行路径，也可能改变原任务后续执行的时间。
一次中断，不只是一次函数调用
任务执行过程中可能发生中断。处理器随后进入相应中断路径， 执行中断处理逻辑，并按照处理器和内核的具体机制返回或转移控制流。
- 中断响应时间受目标处理器、中断优先级和中断屏蔽状态等条件影响。
- 中断服务程序的执行时间会影响被打断任务的后续执行。
- 嵌套中断会引入额外的控制流与上下文管理开销。
- 中断退出后是否进行任务切换，取决于内核实现和当时的调度条件。
因此，中断分析不能只测量进入中断到退出中断的时间。 对任务实时性而言，还应明确中断对任务执行路径和响应时间的影响。
从执行路径到时间分析
时间结论必须绑定具体路径、起止边界和分析假设。
建立可解释的时间模型
执行时间必须对应明确的代码路径和测量边界。 不同路径可能具有不同的指令序列、分支条件、中断干扰与上下文处理开销。
以上各项是便于分析的时间分解方式，不表示每条路径都会包含所有项目， 也不能在没有检查路径边界的情况下直接相加。 如果某项不存在，应明确排除；如果不同阶段发生重叠，则应避免重复计数。
WCET（Worst-Case Execution Time）关注指定执行对象在规定分析条件下的最坏执行时间上界。 如果分析目标包含中断干扰、调度等待或资源阻塞，还必须明确这些因素属于 WCET 计算范围，还是需要在响应时间分析中单独处理。
执行路径如何结束或转移？
对持续运行的嵌入式任务，需要先定义“一次执行”的分析边界。
完成、阻塞与再次调度
执行路径结束后，系统可能出现多种情况，而不是每次都进入相同的“完成与返回”阶段。
- 继续执行：当前任务尚未让出处理器，继续运行其后续代码。
- 主动阻塞或让出：任务等待事件或主动调用内核服务，调度器可能选择其他任务。
- 任务切换：内核保存必要上下文，并恢复另一个可运行任务。
- 中断返回：根据实际控制流恢复原有执行路径，或进入内核定义的后续路径。
对持续运行的嵌入式任务而言，“一次执行完成”通常需要人为定义边界， 例如一次消息处理、一轮控制计算或一次指定函数调用。 只有明确边界，才能对该路径进行重复测量和时间分析。
从执行流到实时性验证
把抽象的实时性要求转化为可定位、可分析、可复核的工程证据。
形成完整的验证链路
- 明确对象：确定目标任务、事件、函数路径或内核操作。
- 明确边界：规定从哪个事件或指令位置开始，到哪个位置结束。
- 识别干扰：分析中断、临界区、上下文切换及资源访问等相关因素。
- 建立证据：结合反汇编分析、目标硬件测量和压力测试，分别记录结果与适用条件。
- 评估约束：将有依据的时间结果与指定的响应时间或截止时间要求比较。
执行路径可分析，不等于已经证明整个系统具有硬实时保证。 最终结论仍取决于路径覆盖范围、最坏情况假设、系统负载及验证证据的完整性。
执行流的工程意义
从理解处理器如何运行，到理解时间结论在什么条件下成立。
语义总结
执行流连接了任务代码、内核控制路径、中断处理与调度机制。 它提供了一种明确分析对象和时间边界的方法，使系统行为能够逐步接受测量、分析和验证。
对 HRTOS 而言，重点不只是让任务按预期执行， 还包括理解执行路径为什么发生、控制流何时转移，以及时间结论在什么条件下成立。