全部学习汇总: https:///GreyZhang/hack_autosar

       继续学习AUTOSAR,看一下官方文档。

893_AUTOSAR_TPS_SoftwareComponentTemplate3_概念_运行时1_数据一致性

893_AUTOSAR_TPS_SoftwareComponentTemplate3_概念_运行时1_优先级_02

       2.3 运行时和数据一致性方面

       2.3.1 背景:问题

       本节提供了一些背景信息,并列出了有关 RunnableEntity 和 RTE 实现的可能策略,以实现 RunnableEntity 之间的有效通信。

       RunnableEntity 之间的通信可以通过“共享内存”的方式非常高效地实现。

       这在技术上是可行的,因为它始终保证 AtomicSwComponentType 中的 RunnableEntity 始终聚集在特定的处理单元(换句话说:分发不是一种选择)。

       请注意,RunnableEntity 之间通信的目的是建立数据流方案。 后者是控制理论在汽车嵌入式系统中应用的一种非常流行的模式。 因此,如果“全局变量”用于在 RunnableEntity 之间建立内部通信,它们将获得所谓状态消息的语义。

       然而,RunnableEntity 之间直接共享内存需要解决一个严重的问题:通信的 RunnableEntity 之间数据一致性的保证。RunnableEntity 确实会映射到任务,这样 AtomicSwComponentType 的一个 RunnableEntity 可能会被同一 AtomicSwComponentType 的不同 RunnableEntity 抢占。

       请注意,实现数据一致性的纯粹方法不仅适用于并发访问变量的单次访问。 相反,不允许在 RunnableEntity 的运行时无意中更改并发访问的变量(具有状态消息语义)的值。

以下段落描述了一些可用于确保所需数据一致性的常见策略。 我们不试图描述这些方法的优缺点。

893_AUTOSAR_TPS_SoftwareComponentTemplate3_概念_运行时1_it技术_03

       2.3.1.1 带有信号量的互斥

       多线程操作系统提供互斥(互斥信号量)来保护对在多个任务中使用的独占资源的访问。

       RTE 可以使用这些操作系统提供的互斥体来确保共享内存空间的 RunnableEntity 永远不会同时运行。  RTE 将确保运行 RunnableEntity 的任务在访问 RunnableEntity 之间共享的内存之前已采用适当的互斥锁。

893_AUTOSAR_TPS_SoftwareComponentTemplate3_概念_运行时1_数据一致性_04

       2.3.1.2 中断禁用

       另一种选择是在 RunnableEntity 的运行时间期间或至少在与 RunnableEntity 中并发访问的变量从第一次到最后一次使用的时间间隔相同的时间段内禁用中断。 这种方法可能会导致严重的非确定性执行时间。

893_AUTOSAR_TPS_SoftwareComponentTemplate3_概念_运行时1_autosar_05

       2.3.1.3 优先级天花板

       优先级天花板允许对共享资源进行无阻塞保护。 如果优先级方案是静态的,AUTOSAR OS 能够临时将尝试访问共享资源的任务的优先级提高到所有尝试访问该资源的任务的最高优先级。

       通过这种方式,临时拥有资源的任务永远不会被试图访问该资源的任务抢占,这在技术上是不可能的。

893_AUTOSAR_TPS_SoftwareComponentTemplate3_概念_运行时1_互斥_06

       2.3.1.4 通过变量副本的隐式通信

       另一种选择是使用具有状态消息语义的并发访问变量的副本。 请注意,这种方法直接对应于“隐式”发送方-接收方通信的语义(见 7.5.1.2)。

       这特别意味着对于并发使用的变量,会创建一个副本,RunnableEntity 实体可以在该副本上工作而不会出现任何数据不一致的危险。

       这个概念需要额外的代码来在执行访问变量的 RunnableEntity 之前将并发访问的变量的值写入副本。 在 RunnableEntity 终止后,副本的值应写回到并发访问的变量中。

       这个概念在图 2.4 中进行了概述。 由于手动复制例程太昂贵且容易出错,因此将附加代码的创建留给合适的代码生成器将是一个好主意。

       如图 2.4 所示的附加复制例程已经保护特定的 RunnableEntity 免受并发访问变量的意外更改。 但是,可以通过减少每个任务开始和结束时的附加代码来进一步优化流程(见图 2.5)。

893_AUTOSAR_TPS_SoftwareComponentTemplate3_概念_运行时1_数据一致性_07

893_AUTOSAR_TPS_SoftwareComponentTemplate3_概念_运行时1_优先级_08

       2.3.2 运行时的数据一致性

       此外,复制例程只会在适当的地方插入,例如,只有当 RunnableEntity 对并发使用的变量具有写访问权限时,才会插入用于将副本的值写回并发访问变量的复制例程。

       请注意,复制例程必须暂时确保复制过程不被中断,以便能够始终如一地将值复制到并发访问的变量中。

       然而,与 RunnableEntity 的整体运行时消耗相比,这些时间段应该非常短,因此不会对运行时行为产生重大影响。

       可以应用进一步的优化标准,例如:避免为调度在任务中的 RunnableEntity 创建副本是完全安全的,这些任务在(通过包含的 RunnableEntity)访问某个并发访问变量的所有任务中具有最高优先级。

       为了使应用程序代码不受代码生成的任何依赖,对并发访问变量的访问将由稍后由代码生成器解析的宏保护。

       守卫宏的存在直接支持了源代码层面的重用。 只有在调度场景(在将 RunnableEntity 分配到优先级方面)没有改变时,才可能在目标代码级别上重用。

       只有在可以识别相关变量的情况下,才能借助代码生成器正确实现这一概念。 换句话说:AtomicSwComponentType 的描述必须向外界公开所有并发访问的变量。

       这部分引入了运行时的一些概念和问题,然后针对并发访问的数据一致性解决方案以及优先级冲突等解决方案给出了一些相关的描述。