Нелюбители UE могут закидать помидорами, но вопрос не о том, что круче и удобнее, а о том, как сделать синхронизацию удобнее.
Вот абстрактный проект. Всё взаимодействие на событиях
Сначала делаю модуль (зелёный), у него свои компоненты. Их надо синхронизировать на старте.
Дальше этот модуль становится частью другого модуля (бордовый), там свой набор частей.
Ну и дальше можно слои наращивать (в теории бесконечно).
И тут возникает гонка вооружений состояний по принципу "кто первый встал, того и тапки". Верхний слой может скомандовать что-то нижним уровням ещё до того, как они зарегистрировали отслеживание события. Ждать по 10 сек на старте, чтобы "уж точно все" - не вариант. Вариант, конечно, но очень кривой.
Отправлять снизу сообщение "я готов" - тоже так себе затея, потому что хочется уйти от жестких завязок на количество компонентов, иначе на каждом уровне надо собрать информацию о готовности нижних, и только потом сообщать выше, что все готовы. Тем более, что тут та же проблема - нижний может сообщить о готовности до того, как верхний сам будет готов.
Я пока придумал только такой вариант через рандеву
Есть саб, создающий рандеву. У него на входе - количество компонентов. На каждом уровне модульности ожидания вызываю эту функцию, а только потом делаю всё остальное. Если ссылка уже есть, размер рандеву уменьшаться не будет
И есть вторая (клонова) функция, которая ждёт, когда все придут на свидание.
В проекте это выглядит примерно так
13 кусков кода должны дождаться общего старта. Справа сверху - функция ожидания синхронизации.
Справа снизу - модуль, в котором история повторяется, там 12 частей, из которых некоторые на ещё более глубоком уровне.
В целом всё норм кроме одного. Если добавляю на какой-то уровень новый компонент, нужно прибавить 1 к числу на каждом уровне выше. Т.е. это ручная работа, которая может создать проблему, оосбоенно, если над проектом работает несколько человек. Один что-то прибавил, второй об этом не узнал. В итоге часть сообщений пролетела мимо.
Думал, можно узнать в системе количество клонов функции, но нет, такой радостной информации не нашёл.
Может, у кого етсь идею более удачного решения этой задачи?
синхронизация на старте (UE)
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 126 раз
- Контактная информация:
Re: синхронизация на старте (UE)
Тоже, не мудрствуя лукаво, использую рандеву, если надо несколько потоков синхронизировать, или порой ещё проще: создаю логическую очередь, подчинённые циклы по готовности помещают элемент в очередь, в главном цикле считаю кол-во элементов в ней. Конечно, не элегантно и завязано на hard-coded константу. Но особо думать бывает некогда. А так, тоже интересно послушать, у кого какие решения по синхронизации.
-
taras_33
- professional
- Сообщения: 391
- Зарегистрирован: 31 окт 2009, 18:25
- Награды: 1
- Версия LabVIEW: 2019
- Поблагодарили: 13 раз
- Контактная информация:
Re: синхронизация на старте (UE)
Достаточно часто применяю эту модель, когда использую AF. Все модули (Actors) наследуются от родителя, в котором переопределяется метод Pre Launch Init, где инициализируются UE Главный контроллер запуская модули, ждет от них ответа о успешных инициализации и запуске. Ответ содержит ID модуля, enqueuer и reference его фронтальной панели, если это необходимо конечно. В случае с UI reference нужен. После получения необходимых ответов, контроллер показывает FP, которая при запуске скрыта. кроме того посылается сообцение модулю, где генерируется UE с неоходимым временем цикла. Цикл начитает "крутится" При добавлении/удалении модуля достаточно обновить typedef Actor ID, по количеству элементов которого определяется необходимое количество ожидаемых ответов.Отправлять снизу сообщение "я готов" - тоже так себе затея, потому что хочется уйти от жестких завязок на количество компонентов, иначе на каждом уровне надо собрать информацию о готовности нижних, и только потом сообщать выше, что все готовы. Тем более, что тут та же проблема - нижний может сообщить о готовности до того, как верхний сам будет готов.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!
So far, the Universe is winning!
-
- professor
- Сообщения: 3394
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: синхронизация на старте (UE)
Инициализировать не достаточно, надо их зарегистрировать. У вас не нашёл отправки сообщения ПОСЛЕ регистрации событий, которые созданы в Pre
-
IvanLis
- guru
- Сообщения: 5462
- Зарегистрирован: 02 дек 2009, 17:44
- Награды: 7
- Версия LabVIEW: 2015, 2016
- Откуда: СССР
- Благодарил (а): 28 раз
- Поблагодарили: 86 раз
Re: синхронизация на старте (UE)
Я примерно так тоже делаю, но это не универсальный вариант, о котором был вопрос.
Т.к. в TypeDef жесткая привязка, что бы идентифицировать Actor, от которого получено подтверждение.
Я только в цикле, например с таймингом (например) 100мс делаю проверку, что все Actor прислали подтверждение, а потом уже иду дальше... Вот например, ожидание ответа от встраиваемых панелей, но это все "жесткое" решение.
Знание нескольких принципов освобождает от знания многих фактов!
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
-
taras_33
- professional
- Сообщения: 391
- Зарегистрирован: 31 окт 2009, 18:25
- Награды: 1
- Версия LabVIEW: 2019
- Поблагодарили: 13 раз
- Контактная информация:
Re: синхронизация на старте (UE)
Так они и регистрируются, когда актор запускается.Инициализировать не достаточно, надо их зарегистрировать
Как я писал в предыдущем посте, после получения ответа, сравнивается количество ответов с количеством всех акторов и если оно равно (все запустились), то посылаем каждому сообщение о запуске UI. Получив этот message, актор генерирует UE, устанавливая вместо -1 тайм-аут в while loop UI. Вот упрощённый вариант Соглашусь что привязка есть, но не такая уж и жёсткая. Изменил typedef, какие их ID, имеют ли они UI, без разницы , главное количество. Но повторюсь, это простой случай.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!
So far, the Universe is winning!
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение