Actor Framework

[Kosist]

Возможно ли как то получать информацию о количестве сообщений в очереди, от кого они были посланы? Может вообще можно эту самую очередь очистить?
Спасибо.

Стандартными способами - нельзя ни узнать инфу о количестве сообщений, ни очистить очередь.
Я бы посоветовал сделать helper loop для актора, которому посылаются сообщения.
Философия акторов такова, что они должны всегда быть доступными для приема и обработки сообщений.
Поэтому, сделайте так что когда актор получит сообщение, он его "перенаправит" в цикл-помощник, через обычную очередь. А уже в этом цикле Вы можете обрабатывать сообщение и контролллировать количество сообщений в ней.
Плюс еще выгода такого решения - не нужно переделывать остальные акторы, а только тот актор в котором Вы обрабатываете сообщения.

[Juri]

Возможно это поможет. Помимо основного сообщения я к нему всегда прикрепляю очередь Handshake. На картинке отправка сообщения актору. Этот код не завершится до тех пор пока актор не отправит ответ через Set Occurrence.vi либо пока не истечет timeout.
Handshake это одноразовая очередь, которая уничтожается сразу как только в нее поступит одно сообщение.
Это поможет контролировать ход исполнения задачи и не посылать новые сообщения актору, пока он обрабатывает старое. Мне пригождается не только в акторах, а вообще везде, где есть параллельные циклы обработки разных задач.
Пароль 113

[Kosist]

Возможно это поможет. Помимо основного сообщения я к нему всегда прикрепляю очередь Handshake.

Авторы Actor Framework в предали бы Вас анафеме В AF либке есть Reply Message, который "заставляет" акторов быть синхронными - но т.к. это не соотвествует "философии" акторов, NI не делало скриптинг-инструменты для создания таких сообщений, чтобы сделать их использование для пользователей максимально неудобным.
Смысл акторов в том, что они исполняются асинхронно. А если нужно отслеживать порядок исполнения - то значит что-то не так с архитектурой акторов...
Верю, что в Вашем случае код работает и все хорошо - и это отлично - но это неправильный паттерн для акторов.

[jane_wild]

Стандартными способами - нельзя ни узнать инфу о количестве сообщений, ни очистить очередь.
Я бы посоветовал сделать helper loop для актора, которому посылаются сообщения.
Философия акторов такова, что они должны всегда быть доступными для приема и обработки сообщений.
Поэтому, сделайте так что когда актор получит сообщение, он его "перенаправит" в цикл-помощник, через обычную очередь. А уже в этом цикле Вы можете обрабатывать сообщение и контролллировать количество сообщений в ней.
Плюс еще выгода такого решения - не нужно переделывать остальные акторы, а только тот актор в котором Вы обрабатываете сообщения.

Интересная идея обязательно попробую.

[ujin1]

Возможно ли как то получать информацию о количестве сообщений в очереди, от кого они были посланы? Может вообще можно эту самую очередь очистить?
Спасибо.

Стандартными способами - нельзя ни узнать инфу о количестве сообщений, ни очистить очередь.

Пытаюсь скрестить синхронные и асинхронные действия.
Немного размышлений по акторам
Actor Core – ждет сообщения из очереди Send-To-Self Enqueuer
При нормальной работе актор не выходит из цикла.
Выполнить какие либо действия можно только в этом цикле и только через очередь. Не используя очередь передать данные нельзя. Не передав сообщение Актору он будет все время в ожидании сообщения.
Выполнить действие (Do) по заранее определенному заданию нельзя не отправив сообщение. Таким образом смешивается очередь сообщений и очередь заданий.

Для организации периодически выполняемых действий, например чтение данных необходимо сделать вспомогательный цикл синхронизации, который будет отправлять самому себе сообщение о выполнении необходимого действия.
Поставить в очередь «синхроимпульс» можно. Однако если актор притормозил нужен только один последний. Нет возможности не закидывать актора сообщениями стандартным способом. Это основной принцип Actor Framework, инкапсуляция очереди.
Приоритеты не поддерживаются стандартной очередью Labview. Автору пришлось сильно постараться с классом Priority Queue. Что не может не вызвать дополнительные накладные расходы при постановке в очередь и чтение очереди.
Работа в RT системах. Не нашел опыта применения.
Накладые расходы на инкапсуляцию очереди и создание приоритетов
Я поместил очередь в Actor без класса Message Enqueuer. Так же упростил Priority Queue убрав приоритеты, как было в первоначальных версиях по словам автора.
Т.е. переделал классы Actor и Меssage.
Производительность возросла в 10 раз. Таким образом оплата за инкапсуляцию и(или) приоритеты - уменьшение производительности в 10 раз
В этом тесте я отправлял целое число в виде и контролировал через DVR что число приходит. Одновременно запустил 10 000 акторов.

Переделанные классы без приоритетов и инкупсуляции очереди

Так же непонятно назначение классов Message Dequeuer.lvclass и Message Queue.lvclass
В описании для использования только в акторе верхнего уровня. В примерах и библиотеке данные классы нигде не использованы.
Вопрос 1. Как более правильно организовать периодически повторяющиеся действия?
Вопрос 2. Как не записывать в очередь сообщение с «синхроимпульсом» если этот тип сообщений уже есть в очереди? Кроме уже упомянутого способа организовать еще одну внутреннюю очередь и еще одного принимающего актора.
Вопрос 3. Есть опыт применения в RT (На NI LinuxRT)?

[IvanLis]

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

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

Для того чтобы тормознуть весь этот процесс при необходимости, добавляем Flag (True/False) - читать или выходить из "цикла".

[ujin1]

Причем запуск опроса шины вызывается именно из метода опроса, т.е. он сам себя вызывает (через Message).

Я не про то. Использовался ли Actor Framework в программах на контроллерах.
Разбор дальше
Добавил приоритет в класс Message.
В класс Priority Queue добавляем буфер сообщений. Каждое сообщение содержит приоритет. Соответственно очередь в виде буфера можно отсортировать.

Priority Queue.png (13.31 КБ) 678 просмотров

В очереди должно быть мало элементов, так как если будет много, значит актор не работает. Это из описания на форумах
В очереди скорее всего будут элементы с приоритетом Notmal, следовательно сортировка закончится на первом же элементе.
Аварию можно передать через Notifier. Ждать в отдельном цикле ядра и удалить очередь, очистить буфер.
Переделываем методы в классе Message Priority Queue.

Для того чтобы уходить в ожидание при пустом буфере оставляем очередь Wait Msg, но с одним элементом. Что означает поступил один или более элементов
Таким образом все свойства остаются. Инкапсуляция, защита очереди. Так как буфер очереди под DVR исключена гонка записи очереди. При прочтении последнего элемента очистится очередь. Если за время между очисткой очереди и чтением буфера произойдет запись, то в буфере будет уже 2 элемента и на следующе цикле чтения очередь снова очистится.
Сортировка в методе Priority Enqueue, то есть при записи в очередь. Можно и при чтении из очереди поставить.
Таким образом производительность по сравнению с стандартным актором можно улучшить в 4 раза. Сохранив инкапсуляцию
Так как в этом тесте очередь не росла инкапсуляция увеличивает время обработки сообщений в 1,8 раза. По сравнению с очередью без инкапсуляции.

Так же если предполагается накопление буфера сообщений актора, можно ограничить очередь разумным значением например 1000 элементов и применить кольцевой буфер. Тогда запись и чтение будет более быстрой, чем вставка в массив и удаление из массива.
Или я что-то недопонял в необходимости сложной реализации автором Priority Queue.

[ujin1]

Использовался ли Actor Framework в программах на контроллерах.

Провел тест. Отправка сообщения Sync. Наследник класса Message. Без пауз 10000 акторам
Испытуемый Orange PI. В некоторых тестах зависал.
В этом загрузка по около 80 % по всем четырем ядрам. Температура 82 С. Больше часа проработал и не виснет.
Можно сделать осторожный вывод: Передача сообщений типа класс Message содержащий одно целое число надежна и не вызывает зависаний.
Неожиданно. Думал сразу процесс lvrt упадет.