Запретить подписчикам временно читать определенные образцы
У нас есть ситуация, когда есть 2 модуля, один из которых имеет издателя, а другой подписчик. Издатель собирается опубликовать некоторые образцы, используя ключевые атрибуты. Возможно ли, чтобы издатель запретил подписчику читать определенные образцы? Этот случай может возникнуть, когда модуль с издателем в настоящее время обновляет образец, который он не хочет, чтобы кто-либо еще читал, пока это не будет сделано. Что-то вроде мьютекса. Мы планируем использовать Opensplice DDS, но, пожалуйста, предоставьте свои данные, даже если они не относятся к Opensplice. Благодарю.
3 ответа
Если я правильно понимаю ваш вопрос, то не существует собственного механизма DDS для достижения того, что вы ищете. Вы написали:
Этот случай может возникнуть, когда модуль с издателем в настоящее время обновляет образец, который он не хочет, чтобы кто-либо еще читал, пока это не будет сделано. Что-то вроде мьютекса.
В DDS нет такой вещи как "глобальный мьютекс".
Однако я подозреваю, что вы можете достичь своей цели, добавив некоторую информацию в модель данных и скорректировав логику своего приложения. Например, вы можете добавить поле перечисления к вашим данным; скажем, вы добавляете поле с именем status и он может принимать одно из значений CALCULATING или же READY,
На стороне издателя вместо "взятия мьютекса" ваше приложение может опубликовать образец с status значение установлено в CALCULATING, Когда расчет закончен, новый образец может быть записан со значением status установлен в READY,
На стороне подписчика, вы можете использовать QueryCondition с status=READY как его выражение. Прочитать или выполнить действия следует только через QueryCondition, с помощью read_w_condition() или же take_w_condition(), Всякий раз, когда статус не равен READYподписавшая сторона не увидит никаких образцов. Этот подход использует преимущества механизма, который новые образцы перезаписывают более старые, предполагая, что для глубины вашей истории установлено значение по умолчанию 1.
Если это приводит к поведению, которое вы ищете, то у этого подхода есть два оставшихся недостатка. Во-первых, логика приложения несколько загрязняется при использовании status поле и QueryCondition, Это может быть легко скрыто слоем абстракции. Можно было бы даже спрятать его за интерфейсом блокировки / разблокировки. Второй недостаток связан с тем, что при установке status поле для CALCULATING, Но в любом случае нельзя избежать лишних коммуникаций, если вы хотите реализовать распределенную мьютекс-подобную функциональность. Только если ваши образцы довольно большие и / или частые, это проблема. В этом случае вам, возможно, придется прибегнуть к отдельной небольшой теме с единственной целью - имитировать механизм блокировки.
RTI Connext DDS предоставляет возможность координировать записи (в документации как "когерентная запись", см. Раздел 6.3.10, и QoS PRESENTATION.
myPublisher->begin_coherent_changes();
// (writers in that publisher do their writes) /* data captured at publisher */
myPublisher->end_coherent_changes(); /* all writes now leave */
С Уважением,
Покойся с миром
ПРЕЗЕНТАЦИЯ Qos не является специфическим для RTI Connext DDS. Это часть спецификации OMG DDS. При этом способность записывать согласованные изменения в нескольких DataWriters/Topics (в отличие от использования одного DataWriter) является частью одного из необязательных профилей (профиль объектной модели), поэтому не все реализации DDS должны его поддерживать.
Херардо