Если я правильно понял ваш вопрос правильно, то нет родного механизма ДДС, чтобы добиться того, что вы ищете. Вы писали:
Этот случай возникнет, когда модуль с издателем в настоящее время обновляет образец, который он не хочет, чтобы кто-либо еще читал его до его завершения. Что-то вроде мьютекса.
В DDS нет такой вещи, как «глобальный мьютекс».
Однако я подозреваю, что вы можете достичь своей цели, добавив некоторую информацию в модель данных и отредактировав логику приложений. Например, вы можете добавить поле перечисления в свои данные; предположим, вы добавили поле под названием status и оно может принимать одно из значений CALCULATING или READY.
На стороне издателя вместо «принятия мьютекса» ваша заявка может опубликовать образец с значением status, установленным на CALCULATING. Когда расчет закончен, новый образец можно записать со значением status, установленным на READY.
На стороне абонента вы можете использовать QueryCondition с status=READY в качестве своего выражения. Прочитать или предпринять действия следует только через QueryCondition, используя read_w_condition() или take_w_condition(). Всякий раз, когда статус не равен READY, подписная сторона не увидит никаких образцов. Этот подход использует механизм, при котором новые образцы перезаписывают более старые, при условии, что для вашей глубины истории установлено значение по умолчанию 1.
Если это приводит к поведению, которое вы ищете, то есть два оставшихся недостатка к этому подходу. Во-первых, логика приложения несколько загрязняется использованием поля status и QueryCondition. Однако это можно было бы скрыть слоем абстракции. Было бы даже возможно скрыть это за некоторым интерфейсом с блокировкой/разблокировкой.Второй недостаток заключается в том, что дополнительный образец проходит по проводу при установке поля status на CALCULATING. Но дополнительных коммуникаций нельзя избежать в любом случае, если вы хотите реализовать распределенную мьютекс-подобную функциональность. Только если ваши образцы довольно большие и/или очень частые, это проблема. В этом случае вам может потребоваться специальная небольшая Тема для единственной цели моделирования механизма блокировки.
Ваш вопрос не совсем ясен для меня. Вы говорите: этот случай возникнет, когда модуль с издателем обновит ** ** образец_. Обновление одного образца всегда является атомарным с DDS. Предполагая, что вы ищете механизм, похожий на транзакцию * нескольких * образцов, тогда важно знать, написаны ли образцы в вашей транзакции одним и тем же DataWriter - вы упоминаете только издателя, вы хотели сказать DataWriter? –
Извините, что не ясны. Да, издателем Я имею в виду DataWriter, и образцы в транзакции записываются одним и тем же DataWriter. Я постараюсь быть более ясным. Когда я говорю об обновлении образца, я имею в виду, что модуль выполняет некоторую обработку, и именно в это время (то есть, когда он обрабатывает данные, которые собираются обновить образец), что я хочу запретить подписчикам читать образец , Я в основном хочу убедиться, что ни один из подписчиков не читает образец, когда я знаю, что обновление будет опубликовано. Надеюсь, это станет более ясным, но дайте мне знать, если нет. – shamshu
ОК, так что звучит так, будто вы хотите «заблокировать» DataReader для определенного образца во время выполнения ваших вычислений. Затем, когда расчет завершен, вы хотите записать образец и разблокировать DataReader. Похоже на блокировку уровня записи в базе данных. Это правильно? –