OSEK资源管理

斯安

已于 2024-05-19 03:19:16 修改

阅读量606

点赞数 27

分类专栏： RTOS AUTOSAR 文章标签：车载系统

于 2024-05-19 02:56:28 首次发布

本文链接：https://blog.csdn.net/m0_47462420/article/details/139033304

版权

RTOS 同时被 2 个专栏收录

12 篇文章 1 订阅

订阅专栏

AUTOSAR

8 篇文章 0 订阅

订阅专栏

1 前言

资源管理（resource management）用于协调不同优先级的多个任务对共享资源的并发访问，共享资源包括管理实体（调度器），内存或硬件资源等。

资源管理对于所有一致类（conformance classes， CC）的要求都是一致的，且可以选择拓展资源管理，以协调任务和中断服务函数（ISR)对共享资源的并发访问。

资源管理需要确保以下几个方面：

• 两个任务不能同时占用同一个资源；
• 避免优先级反转（priority inversion ）；
• 在共享资源的使用过程中，不可发生死锁（deadlocks ）；
• 对资源的访问不会导致进入等待状态（ waiting state）；

如果资源管理的维度拓展至中断级别（interrupt level），则还必须额外保证：

• 任意两个任务或ISR也不可同时占用同一个资源。

因此，资管管理主要是针对不同优先级的调度对象的共享资源来制定规则，其应用情形主要包括以下几个方面：

• 抢占式任务；
• 不可抢占式任务，且其代码也需要在其他调度策略下执行
• 任务与ISR之间的共享资源；
• ISR之间的共享资源。

显然，不同优先级代表着抢占可能会发生，而抢占必然导致打断。如果打断了对共享资源的访问，则上下文恢复后，被抢占的任务/ISR对共享资源的访问大概率会出现错乱，这是资源管理需要解决的主要问题。

2 共享资源访问行为

OSEK采用了资源优先级上限（天花板）策略，以避免发生任务或中断试图访问一个已被占用的资源。如果资源管理的维度包括了中断级别，则OSEK还需要保证当一个ISR所需的所有资源都是已释放状态时，该ISR才会得以执行。

此外，OSEK严格禁止对同一资源的嵌套访问。在那些需要嵌套访问的特殊场景下，应启用与第一个资源同行为的第二个资源。

在一个任务中占用多个资源的情况下，必须按照后进先出原则(LIFO principle，类似堆栈)请求和释放资源。在任务的处理过程中，在资源被占用（未释放）的情况下，不可调用TerminateTask，ChainTask， Schedule，WaitEvent等系统接口，即资源的占有和释放必须成双成对，一一对应，就地解决，有始有终。类似地，ISR也不能在资源被占用的情况下完成执行。

特别地，调度器（scheduler）可以看作是一种特殊的共享资源，它为所有任务所共享，通常由预定义命名为RES_SCHEDULER的资源来表示。因此，对于任务间的共享资源管理，可以通过给调度器上锁（即关调度）来实现资源的互斥访问。

3 同步机制的共性问题

3.1 优先级反转

如图1所示，任务T1~T4的优先级由高到低，且S1为T1和T4的共享信号量。

① 在某一时刻，T4处于运行态，并占用S1；

② 随后T1，T2，T3同时进入就绪态，T4被优先级最高的T1抢占执行，T1在运行过程中请求S1而进入等待状态（S1被T4占用，未释放）；

③ 调度发生后，T2进入运行态，执行完毕后，优先级次低的T3获得CPU的使用权，进入运行态；

④ T3运行完毕后，T4终于等到了三十年河西，继续运行，并资源使用完毕后释放S1，随即唤醒了等待S1的T1，再次被T1抢占执行。

图1 优先级反转示意图

显然，T1在发起对共享资源S1的请求后，其进入运行态主要包括两个条件，即获得S1以进入就绪态，且在所有就绪态的任务中优先级为最高。优先级这一条件显然是满足的，现在只欠东风了。然而，占用S1的T4一直被T2和T3抢占执行，这显然会导致T1的优先级名不副实，导致其执行还要在T2和T3之后，这就是所谓的优先级反转问题。

优先级反转的核心问题在于，优先级最高的T1由于等待优先级最低的T4释放共享资源S1，导致其额外被迫等待优先级较低的T2和T3执行完毕。

3.2 死锁问题

死锁（deadlock），指的是由于任务间相互无限等待被对方占用的共享资源，而导致双方任务都无法继续执行的现象。

图2 死锁现象示意图

如图2所示，任务T1的优先级较高，则有：

① 任务T1执行，占用S1，直至需要等待一个事件而进入等待状态；

② 随即T2得以执行，并占用S2；

③ T1被事件唤醒，继续抢占T2执行，随即试图申请访问S2，由于S2被T2占用且未释放，T1进入等待状态；

④ T2重新获得CPU使用权，并在后续的执行中试图申请访问S1（已被T1占用，且未释放），导致T2进入等待状态；

至此，任务T1和T2进入互相等待资源释放的死锁状态，无一能得到执行。

4 优先级上限（天花板）协议

为了解决上述优先级反转和死锁问题，OSEK采用了优先级上限协议（Priority Ceiling Protocol），其本质就是对占用共享资源的任务进行优先级提升，具体做法如下：

• 在系统生成时，每个资源都会通过静态分配指定其上限优先级（ceiling priority）；

• 上限优先级的大小必须大于或等于所有占用该资源的任务的优先级的最大值（设为ceiling)；同时也不宜过高，即不应高于那些比ceiiling优先级更高且不占用该资源的任务的优先级，即优先级提升不应该影响到不占用该资源的更高优先级的任务；简单来说，上限优先级最好就取值ceiling，最为方便；
• 当一个任务占用资源时，若该任务当前的优先级低于上限优先级，则应（临时）将该任务的优先级提升至该资源对应的上限优先级；
• 在一个任务释放资源时，如果其优先级被动态提升过，则应将其优先级恢复成本来面貌，即恢复成请求资源前的优先级；

诚然，上述方法使得占用该资源的任务，不会被优先级比资源上限优先级低（或相等）的任务抢占；避免了请求资源的高优先级任务，被一些与该资源不相干的较低优先级任务（如图1中的T2/T3）阻塞执行的情形；但对占用该资源的较低优先级任务进行优先级提升，同样也可能会导致优先级不高于上限优先级的任务被延迟执行，具体的延迟时间取决于资源被占用的时长。

图3 抢占式任务间共享资源上限优先级示意图

如图3所示，任务T0~T4的优先级由高到底，且T1和T4共享同一资源。显然，该资源的上限优先级应不低于T1和T4的最大值，即应等于或高于T1的优先级；同时，由于T0并不使用该资源，且优先级高于T1，所以该资源的上限优先级同时应低于任务T0的优先级。

更进一步地，当资源管理拓展到中断级别时，可以为中断分配一个虚拟优先级，该虚拟优先级显然在更高的维度上，即高于所有任务的优先级，其具体定义要依赖于硬件的实现。除此之外，其余的上限优先级的规则几乎时相同的。

图4 抢占式任务和ISR间共享资源上限优先级示意图

如图4所示，任务T1~T3的优先级从低到高，任务T1和中断INT1共享同一资源；当INT1中断发生时，由于任务T1的优先级被提升至上限优先级，使得中断INT1停留在pending状态；但中断INT2发生时，由于其优先级比上限优先级更高，任务T1的执行被打断，ISR INT2得以执行。

类似地，图5演示了ISR之间的共享资源上限优先级的处理机制。其中，中断INT1~INT3优先级由低到高，且INT1和INT2共享同一资源。

图5 ISR间共享资源上限优先级示意图

5 内部资源

内部资源（Internal Resources）是对用户不可见的资源，即不可通过系统接口GetResource和ReleaseResource来获取，而是受特定的系统函数严格管理。除此之外，内部资源与标准资源完全相同，包括对应的优先级上限协议等。

内部资源仅限于任务，且在系统生成时，一个任务最多只能分配一个内部资源。

如果将内部资源分配给任务，则其对应的资源管理方式如下：

• 当任务进入运行状态时自动获取内部资源，除非该任务已经获取了该资源；
• 随后，任务的优先级自动提升为内部资源的上限优先级；
• 在相应的重调度点上，内部资源被自动释放

OSEK的任务组（Groups of tasks）就是通过内部资源来实现的；而所有的不可抢占式任务的集合就是个特殊的任务组，其共享的内部资源即为RES_SCHEDULER（调度器）。总之，内部资源通常用于避免一组任务间发生没必要的任务抢占。也就是说，一个任务组共享着一个内部资源，而一个系统中可以定义多个任务组，即对应多个内部资源。

资源被占用时，不可调用一些系统接口（如TerminateTask，ChainTask， Schedule，WaitEvent等）的限制，并不适用于内部资源，毕竟内部资源就是在这些系统接口调用中处理的。然而，所有的标准资源都必须在内部资源别释放之前被释放，谁第一个来，谁最后一个走。