保持任务关键的确定性DBMS准时-电子发烧友网

开源和商业数据库管理系统（DBMS）已在嵌入式系统中使用了 20 多年。在大多数情况下，开发人员甚至不会争论是否为嵌入式系统购买或构建自己的 DBMS。该组件几乎总是被购买。

然而，嵌入式系统空间的一个子集仍然禁止商业供应商使用，包括某些医疗系统、辐射监测、飞机导航、航空电子设备、飞行员辅助，以及最近的自动驾驶。总而言之，它们可以被称为具有硬实时约束的任务关键型或安全关键型系统，其中系统故障可能会造成伤害。

许多任务关键型软件团队正在寻找商业现货（COTS）软件以加快开发速度。嵌入式 DBMS 可以提供帮助，但前提是它具有确定性、可预测性和可控性。用于关键任务系统的确定性 DBMS 架构应提供具有时间有效性的 ACID（原子性、一致性、隔离性、持久性）合规性。

不是每个 DBMS 都强制执行 ACID 属性吗？符合 ACID 的数据库很常见，但其架构是针对事务吞吐量而非确定性的。一致性是最重要的属性；事务应该只将数据库从一种有效状态更改为另一种有效状态。在实时系统中，事务中的一组原子语句应该成功提交，或者应该全部中止，但不应在截止日期之后进行。“迟到”会带来不一致的状态，带来暂时无效的数据和可能的可怕后果。

一致性的关键时间断言

确保所有条件下的内部数据库一致性对于时间有效性至关重要。嵌入式数据库在执行效率方面提供了一些改进，但确定性 DBMS 需要更多的架构步骤才能保持准时。

首先，应该使用悲观并发控制。它在授予一项任务访问权限之前锁定全部或部分数据库，从而减少了乐观模型中复制的不确定开销。只读（RO）事务可以并行发生，而读写（RW）事务具有独占访问权限，从而减少了用于锁仲裁和死锁预防的资源。

接下来，一个关键的时间断言说明了工作量和在截止日期前回滚：

无论事务复杂性如何，将任何修改撤销到事务中的任何点的时间都不能超过应用这些修改的时间。

RO事务有索引查找和游标移动操作；回滚以相等的间隔撤消内部计数器的任何递增或递减。

更简单的 RW 事务很容易回滚。创建对象会根据对象大小从空闲内存池中分配页面；反转只是将这些页面返回到池中。其他交易根本不需要冲销。删除一个对象会将其标记为在原子操作中将其删除，因此如果事务中止，则不会发生提交时的删除。在索引中添加或删除对象具有树重新平衡或哈希重新分配，它们仅在提交时生效并且不需要反转。

更新对象看起来更复杂，但结果证明是一种有效的操作。事务第一次更新对象时，分配一个临时对象，然后将原始对象复制到临时对象。使用已经创建的副本，后续更新会更快。回滚以相反的顺序从副本中重新创建原始对象，然后释放分配的内存页，对象的回滚时间与对该对象的更新次数无关。

根据实时截止日期验证交易

确保每个事务都安全地提交或中止后，接下来要安排事务流。回忆悲观并发；RW 事务必须按顺序执行，而 RO 事务可以并行执行。例如，McObject 的 eXtremeDB/rt 中的动态、时间感知的最早期限优先（EDF）调度根据绝对期限为事务分配优先级。

事务管理器代码中的验证点指示事务语句的进展程度。如果事务在提交之前到达控制点（不再保证数据库回滚的时间），那么“事务中断”错误状态将返回给应用程序。事务管理器将数据库恢复到事务开始之前存在的一致状态。

在 eXtremeDB/rt 中，应用程序可以使用两种验证方法：传递给数据库运行时的应用程序回调，或异步事件处理程序。以下示例将控制点设置为截止时间间隔的一半，可以调整。

回调方法伪代码

如果系统定时器或硬件看门狗定时器等异步原语不可用，则可以使用回调方法。操作系统在获取系统时间方面存在细微差别，但代码流程如以下伪代码。首先注册一个回调函数：