Actor Framework

Общие принципы, проектирование, модуляризация, темплейты и шаблоны
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

Re: Actor Framework

Сообщение Kosist »

jane_wild писал(а): 29 апр 2021, 14:34 Возможно ли как то получать информацию о количестве сообщений в очереди, от кого они были посланы? Может вообще можно эту самую очередь очистить?
Спасибо.
Стандартными способами - нельзя ни узнать инфу о количестве сообщений, ни очистить очередь.
Я бы посоветовал сделать helper loop для актора, которому посылаются сообщения.
Философия акторов такова, что они должны всегда быть доступными для приема и обработки сообщений.
Поэтому, сделайте так что когда актор получит сообщение, он его "перенаправит" в цикл-помощник, через обычную очередь. А уже в этом цикле Вы можете обрабатывать сообщение и контролллировать количество сообщений в ней.
Плюс еще выгода такого решения - не нужно переделывать остальные акторы, а только тот актор в котором Вы обрабатываете сообщения.
Мы делили апельсин - много наших полегло...
Аватара пользователя
Juri
I/O
I/O
Сообщения: 262
Зарегистрирован: 19 апр 2017, 23:06
Версия LabVIEW: 2021
Благодарил (а): 13 раз
Поблагодарили: 6 раз

Re: Actor Framework

Сообщение Juri »

Возможно это поможет. Помимо основного сообщения я к нему всегда прикрепляю очередь Handshake. На картинке отправка сообщения актору. Этот код не завершится до тех пор пока актор не отправит ответ через Set Occurrence.vi либо пока не истечет timeout.
Handshake это одноразовая очередь, которая уничтожается сразу как только в нее поступит одно сообщение.
Это поможет контролировать ход исполнения задачи и не посылать новые сообщения актору, пока он обрабатывает старое. Мне пригождается не только в акторах, а вообще везде, где есть параллельные циклы обработки разных задач.
Пароль 113
Вложения
1.png
Handshake.llb
(53.01 КБ) 89 скачиваний
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

Re: Actor Framework

Сообщение Kosist »

Usss писал(а): 29 апр 2021, 16:17 Возможно это поможет. Помимо основного сообщения я к нему всегда прикрепляю очередь Handshake.
Авторы Actor Framework в :labview: предали бы Вас анафеме :haha: В AF либке есть Reply Message, который "заставляет" акторов быть синхронными - но т.к. это не соотвествует "философии" акторов, NI не делало скриптинг-инструменты для создания таких сообщений, чтобы сделать их использование для пользователей максимально неудобным.
Смысл акторов в том, что они исполняются асинхронно. А если нужно отслеживать порядок исполнения - то значит что-то не так с архитектурой акторов...
Верю, что в Вашем случае код работает и все хорошо - и это отлично - но это неправильный паттерн для акторов.
Мы делили апельсин - много наших полегло...
Аватара пользователя
jane_wild
master
master
Сообщения: 459
Зарегистрирован: 30 июн 2016, 02:11
Версия LabVIEW: 2020
Благодарил (а): 83 раза
Поблагодарили: 15 раз
Контактная информация:

Re: Actor Framework

Сообщение jane_wild »

Kosist писал(а): 29 апр 2021, 15:18 Стандартными способами - нельзя ни узнать инфу о количестве сообщений, ни очистить очередь.
Я бы посоветовал сделать helper loop для актора, которому посылаются сообщения.
Философия акторов такова, что они должны всегда быть доступными для приема и обработки сообщений.
Поэтому, сделайте так что когда актор получит сообщение, он его "перенаправит" в цикл-помощник, через обычную очередь. А уже в этом цикле Вы можете обрабатывать сообщение и контролллировать количество сообщений в ней.
Плюс еще выгода такого решения - не нужно переделывать остальные акторы, а только тот актор в котором Вы обрабатываете сообщения.
Интересная идея обязательно попробую.
ujin1
adviser
adviser
Сообщения: 227
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 18 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Actor Framework

Сообщение ujin1 »

Kosist писал(а): 29 апр 2021, 15:18
jane_wild писал(а): 29 апр 2021, 14:34 Возможно ли как то получать информацию о количестве сообщений в очереди, от кого они были посланы? Может вообще можно эту самую очередь очистить?
Спасибо.
Стандартными способами - нельзя ни узнать инфу о количестве сообщений, ни очистить очередь.
Пытаюсь скрестить синхронные и асинхронные действия.
Немного размышлений по акторам
Actor Core – ждет сообщения из очереди Send-To-Self Enqueuer
При нормальной работе актор не выходит из цикла.
Выполнить какие либо действия можно только в этом цикле и только через очередь. Не используя очередь передать данные нельзя. Не передав сообщение Актору он будет все время в ожидании сообщения.
Выполнить действие (Do) по заранее определенному заданию нельзя не отправив сообщение. Таким образом смешивается очередь сообщений и очередь заданий.
Actor Core.png
Для организации периодически выполняемых действий, например чтение данных необходимо сделать вспомогательный цикл синхронизации, который будет отправлять самому себе сообщение о выполнении необходимого действия.
Поставить в очередь «синхроимпульс» можно. Однако если актор притормозил нужен только один последний. Нет возможности не закидывать актора сообщениями стандартным способом. Это основной принцип Actor Framework, инкапсуляция очереди.
Приоритеты не поддерживаются стандартной очередью Labview. Автору пришлось сильно постараться с классом Priority Queue. Что не может не вызвать дополнительные накладные расходы при постановке в очередь и чтение очереди.
Работа в RT системах. Не нашел опыта применения.
Накладые расходы на инкапсуляцию очереди и создание приоритетов
Я поместил очередь в Actor без класса Message Enqueuer. Так же упростил Priority Queue убрав приоритеты, как было в первоначальных версиях по словам автора.
Т.е. переделал классы Actor и Меssage.
Производительность возросла в 10 раз. Таким образом оплата за инкапсуляцию и(или) приоритеты - уменьшение производительности в 10 раз
В этом тесте я отправлял целое число в виде и контролировал через DVR что число приходит. Одновременно запустил 10 000 акторов.
Тест производительности.png
Тест производительности1.png
Переделанные классы без приоритетов и инкупсуляции очереди
Тест производительности2.png
Так же непонятно назначение классов Message Dequeuer.lvclass и Message Queue.lvclass
В описании для использования только в акторе верхнего уровня. В примерах и библиотеке данные классы нигде не использованы.
Вопрос 1. Как более правильно организовать периодически повторяющиеся действия?
Вопрос 2. Как не записывать в очередь сообщение с «синхроимпульсом» если этот тип сообщений уже есть в очереди? Кроме уже упомянутого способа организовать еще одну внутреннюю очередь и еще одного принимающего актора.
Вопрос 3. Есть опыт применения в RT (На NI LinuxRT)?
Изображение
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5452
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: Actor Framework

Сообщение IvanLis »

Смотрите, я много с железками работал, в основном ModBus и у них время опроса сильно плавает.
Например, если опрашивать одну величину, то период один, а если смена режима измерения, то именно на переключение режима, много времени уходит.
Заранее сложно спрогнозировать период опроса всех устройств на шине, ну и естественно значения не тактированы, а каждый отсчет записываем с меткой времени.

Ну а теперь как "крутился" и крутится.
Задается период опроса, например 5 сек. Т.е. чаще, мы устройства не дергаем.
Начинаем опрос первого датчика на шине и запоминаем время.
После получения информации от последнего датчика, вычисляем время затраченное на опрос всей шины и если оно меньше заданного ранее периода, то ждем необходимое время.
Если на опрос было затрачено больше времени, чем задано, то начинаем опрос шины сразу.
Причем запуск опроса шины вызывается именно из метода опроса, т.е. он сам себя вызывает (через Message).

Для того чтобы тормознуть весь этот процесс при необходимости, добавляем Flag (True/False) - читать или выходить из "цикла".
ujin1
adviser
adviser
Сообщения: 227
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 18 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Actor Framework

Сообщение ujin1 »

IvanLis писал(а): 06 фев 2024, 22:26 Причем запуск опроса шины вызывается именно из метода опроса, т.е. он сам себя вызывает (через Message).
Я не про то. Использовался ли Actor Framework в программах на контроллерах.
Разбор дальше
Добавил приоритет в класс Message.
В класс Priority Queue добавляем буфер сообщений. Каждое сообщение содержит приоритет. Соответственно очередь в виде буфера можно отсортировать.
Priority Queue.png
Priority Queue.png (13.31 КБ) 93 просмотра
В очереди должно быть мало элементов, так как если будет много, значит актор не работает. Это из описания на форумах
В очереди скорее всего будут элементы с приоритетом Notmal, следовательно сортировка закончится на первом же элементе.
Аварию можно передать через Notifier. Ждать в отдельном цикле ядра и удалить очередь, очистить буфер.
Переделываем методы в классе Message Priority Queue.
Priority Enqueue.png
Message Dequeuer.png
Для того чтобы уходить в ожидание при пустом буфере оставляем очередь Wait Msg, но с одним элементом. Что означает поступил один или более элементов
Таким образом все свойства остаются. Инкапсуляция, защита очереди. Так как буфер очереди под DVR исключена гонка записи очереди. При прочтении последнего элемента очистится очередь. Если за время между очисткой очереди и чтением буфера произойдет запись, то в буфере будет уже 2 элемента и на следующе цикле чтения очередь снова очистится.
Сортировка в методе Priority Enqueue, то есть при записи в очередь. Можно и при чтении из очереди поставить.
Таким образом производительность по сравнению с стандартным актором можно улучшить в 4 раза. Сохранив инкапсуляцию
Так как в этом тесте очередь не росла инкапсуляция увеличивает время обработки сообщений в 1,8 раза. По сравнению с очередью без инкапсуляции.
Тест производительности3.png
Так же если предполагается накопление буфера сообщений актора, можно ограничить очередь разумным значением например 1000 элементов и применить кольцевой буфер. Тогда запись и чтение будет более быстрой, чем вставка в массив и удаление из массива.
Или я что-то недопонял в необходимости сложной реализации автором Priority Queue.
Изображение
ujin1
adviser
adviser
Сообщения: 227
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 18 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Actor Framework

Сообщение ujin1 »

ujin1 писал(а): 07 фев 2024, 00:35 Использовался ли Actor Framework в программах на контроллерах.
Провел тест. Отправка сообщения Sync. Наследник класса Message. Без пауз 10000 акторам
Испытуемый Orange PI. В некоторых тестах зависал.
В этом загрузка по около 80 % по всем четырем ядрам. Температура 82 С. Больше часа проработал и не виснет.
Можно сделать осторожный вывод: Передача сообщений типа класс Message содержащий одно целое число надежна и не вызывает зависаний.
Неожиданно. Думал сразу процесс lvrt упадет.
Тест производительности4.png
Изображение
Ответить

Вернуться в «Модели программирования»