我们遇到的情况是有 2 个模块,一个有发布者,另一个有订阅者。发布者将使用键属性发布一些示例。发布者是否可以阻止订阅者读取某些示例?当具有发布者的模块当前正在更新示例时,会出现这种情况,在完成之前它不希望其他人读取该示例。类似于互斥锁的东西。我们计划使用Opensplice DDS,但请提供您的意见,即使它们不是特定于Opensplice的。谢谢。
RTI Connext DDS提供了一个协调写入的选项(在文档中称为"连贯写入",请参阅第6.3.10节和PRESENTATION QoS。
myPublisher->begin_coherent_changes();
// (writers in that publisher do their writes) /* data captured at publisher */
myPublisher->end_coherent_changes(); /* all writes now leave */
问候
把
正确理解您的问题,那么没有本机DDS机制可以实现您正在寻找的内容。你写道:
当具有发布者的模块当前正在更新示例时,会出现这种情况,在完成之前它不希望其他人读取该示例。类似于互斥锁的东西。
DDS 中没有"全局互斥锁"这样的东西。
但是,我怀疑您可以通过向数据模型添加一些信息并调整应用程序逻辑来实现目标。例如,您可以向数据添加枚举字段;假设您添加了一个名为 status
的字段,它可以采用CALCULATING
或READY
的值之一。
在发布者端,应用程序可以发布一个示例,而不是"采用互斥锁",status
值设置为 CALCULATING
。计算完成后,可以写入新样本,并将 status
的值设置为 READY
。
在订阅者端,您可以使用带有 status=READY
作为表达式的QueryCondition
。读取或执行操作只能通过QueryCondition
,使用read_w_condition()
或take_w_condition()
来完成。当状态不等于READY
时,订阅方将看不到任何样本。此方法利用较新示例覆盖较旧示例的机制,假设历史记录深度设置为默认值 1。
如果这导致了您正在寻找的行为,那么这种方法还有两个缺点。首先,应用程序逻辑会因使用status
字段和QueryCondition
而受到一定污染。不过,这很容易被抽象层隐藏。甚至可以将其隐藏在一些类似锁定/解锁的界面后面。第二个缺点是由于将status
字段设置为 CALCULATING
时有额外的样本通过线路。但是,如果要实现类似分布式互斥锁的功能,则无论如何都无法避免额外的通信。只有当您的样品非常大和/或频繁时,这才是一个问题。在这种情况下,您可能不得不求助于专用的小主题,以模拟锁定机制。
演示文稿 Qos 不是特定的 RTI Connext DDS。它是OMG DDS规范的一部分。也就是说,在多个 DataWriter/Topics 上编写连贯更改的能力(而不是使用单个 DataWriter)是其中一个可选配置文件(对象模型配置文件)的一部分,因此并非所有 DDS 实现都必须支持它。
杰拉尔多