Autosar模块介绍：AutosarOS（3）

上一篇 | 返回主目录 | 下一篇

1 应用集（OS Application）

应用集（OS Application）为资源组成的功能单元，由中断、调度表、Alarm、任务等构成。在应用集内对象（Object）之间的相互访问是被允许的，而跨越应用集的相互访问需要在配置时对具体的对象进行分配。应用集可以分为可信应用集（Trust OS-Application）和不可信应用集（Non-Trust OS-Application）两大类。

1）、可信应用集（Trust OS-Application）：无内存访问限制、操作系统API以及可不必进行时间保护，可以在特权模式运行，并且假定不会发生内存保护错误（若发生此类错误，系统将会关闭OS或者跑飞）。

包含的对象对大部分内存拥有读写权限，包括所有的Flash、LMU（Local Memory Unit）、CSA（Context Save Areas）以及外设单元等，但是对未激活栈没有读取权限

2）、不可信应用集（Non-Trust OS-Application）：不允许在没有监控及保护的情况下运行，存在内存访问限制、OS相关API访问限制以及时间行为限制，并且不允许运行在特权模式下。

包含的对象只有读取少数内存的权限，如当前活跃的栈、当前OS应用集的数据以及LMU中的共享数据

受信任的OS-Application与不受信任的OS-Application对于内存访问如下图所示。其中深灰色的表示两者兼可访问，浅灰色表示受信任的OS-Application可单独访问内存。

##注意OS- Application与Core的区别，Core为物理含义上的内核，一般存在一个主核（Master Core），其余为从核（Slave Core），启动过程一般为主核启动，然后通过主核启动从核。一个OS Application都必须分配到唯一一Core上，一个Core上可以分配多个OS Application

2 资源管理（Resource management）

资源管理用于协调多个具有不同优先级的任务对共享资源的并发访问，例如管理实体(调度程序)、程序序列、内存或硬件区域。

通过资源管理应达到以下目的：
1）、两个任务不能占用同一资源
2）、不会发生优先级反转
3）、在使用这些资源时不会发生死锁
4）、对资源的访问从不会导致等待状态

2.1 核内资源共享机制

在了解核内资源共享机制之前，简单说明下一个简单的问题——优先级反转。

优先级反转：
1）、TaskA、TaskD共享同一资源（执行时所必须）
2）、TaskD优先级高于TaskA
3）、TaskA执行时先占用共享资源
4）、在共享资源被占用时，Task D无法执行，因此出现TaskB、TaskC先于TaskD执行的情况

天花板协议（解决核内资源访问可能出现优先级反转问题）：
1）、每个资源的上限优先级是静态分配的
2）、资源上限优先级不应低于所有访问该资源的任务优先级
3）、申请到该资源的任务获得此资源同等的优先级
4）、释放该资源后，任务优先级重置为原来的任务优先级

2.2 核间资源共享机制

2.2.1 核间资源访问存在的问题

为实现核间资源互斥，保证数据的一致性，设计了自旋锁（Spinlock）机制。当某一个任务/二类中断成功申请占用自旋锁时，其他任务/二类中断均无法成功申请占用自旋锁，只能等待占用者将其释放，并会处在停滞状态，等待占用者将其释放。因为自旋锁的特点，在使用过程中处理不当将会处于不合理的死锁状态（不同进程间由于竞争资源处于相互阻塞的状态）。以下为几种常见的死锁状况：

1）、高优先级抢占spinlock造成死锁
a）、低优先级占用自旋锁的情况被高优先级的任务占用
b）、高优先级也申请占用同一自旋锁（根据自旋锁机制设定，必须等待低优先级任务释放）
c）、高优先级任务会抢占低优先级任务
d）、由于自选锁机制以及任务优先级的抢占属性，导致两任务处于互锁状态

#自旋锁申请使用时，禁用中断（避免高优先级任务打断低优先级任务执行），完成操作后再恢复再恢复中断，从而可以避免此类互锁状况

2）、嵌套访问Spinlock造成死锁
a）、核0上任务A占用自旋锁A
b）、核1上任务B占用自旋锁B
c）、核0上任务A申请占用自旋锁B（核1上任务B未释放自旋锁B），核1上任务B申请占用自旋锁A（核0上任务A未释放自旋锁A）
d）、两个任务等待对方释放相应的自旋锁获取资源已完成执行，然后释放已占用的自旋锁，从而形成互锁状态

#禁止嵌套使用自选锁的请求或者严格按照顺序嵌套自旋锁的方式进行请求

3）、回环访问Spinlock造成死锁
a)、为了避免嵌套申请自旋锁，采用顺序的访问自旋锁可避免此类情况
b）、若存在回环访问自旋锁，同样会出现嵌套的情况

#需要严格遵循顺序访问规则，以规避可能的问题

2.2.2 核间资源访问解决方案

不同核间需要进行数据传输时，操作系统会为其开辟共享的内存Cache区域，通信双方的应用程序通过对该区域的读写，完成数据传输。核间通信（IOC）在操作系统层面完成，RTE相关接口会转换成调用底层相关IOC接口，访问的同时会申请Spinlock进行对临界区域的保护。

#优先级上限协议(GetResource使用)临时改变Task的优先级。这种方法在多核系统上失败，因为优先级对每个核心都是本地的。因此，上限协议不足以保护临界段免受不同核心的访问。

2.3 核间任务同步实现方式

核间任务提供了一种同步方式，通过OS配置Barrier进行任务间同步。在一个任务调用了Os_BarrierSynchronize()后，这个任务将被阻塞在此处，直到所有关联了此Barrier的任务调用了Os_BarrierSynchronize()后，才会将任务阻塞解除。

#注意事项：
1）、一个核上多个任务不允许关联同一个Barrier，否则将可能会造成死锁（一个任务阻塞占用资源等待另外一个任务调用此同步函数）
2）、一个任务可以关联多个Barrier

3 系统启动/关闭过程（OS Startup/Shutdown）

3.1 多核系统的启动过程

多核的启动和硬件紧密相关，通常情况下，硬件会启动一个核作为主核（Master Core），而从核（Slave Core）由软件启动，这种模式称为主从模式（Master-Slave Startup Behavior）。启动过程如下图所示。

#第二次同步取决于软件的具体实现（参考SWS）

3.2 多核系统的关闭过程

若存在一个任务拥有调用Shutdown All Cores的权限时，关闭信号会被发送至所有核。当关闭过程启动后，所有的中断服务和任务都不会被激活，关闭前必须完成的程序由EcuM保证完成。关闭完成前，由OS Application Shutdown Hooks完成相应的回调程序，然后等待至同步点所有核主席那个关闭回调函数。

4 资源分配依据（Resource Distributed）（*暂时没想好怎么写 *）

5 任务调度优化（Task Schedule）（*暂时没想好怎么写 *）

上一篇 | 返回主目录 | 下一篇