Нашел время и разобрался с Actor Framework. Перечитал тему и для меня не хватило теоретического материала в целом по этому фреймворку. Внесу лепту в развитие темы, но пока без конкретных примеров. Те примеры, которые есть в теме и по приведенным ссылкам - подойдут. Представленный материал был получен в рамках обзора выступлений разработчиков из других отраслей разработки ПО(на примере Akka-фреймворка, который реализует модель акторов). Тем не менее базовая модель программирования совпадает, отличается функциональная составляющая.
Часть 1. Введение
Actor Framework – это модель программирования, в основе которой лежит асинхронный обмен сообщениями между примитивами параллельного исполнения– акторами. Актором может быть объект/поток/процесс, который инкапсулирует данные и предоставляет операции над данными.
Поскольку каждый актор работает в отдельном потоке, то они между собой не делят память. Это позволяет избежать глобального изменяемого состояния(Global mutable state), которое является причиной многих багов в программе. Иными словами модель акторов на архитектурном уровне запрещает изменять глобальный стейт другого актора, т.к. они находятся в разных потоках(thread).
Каждый актор содержит некоторый почтовый ящик, в который прилетают сообщения. При получении сообщения актор может:
а) создать новый актор
б) послать сообщение другому актору
в) назначить поведение для обработки последующего сообщения
Когда один актор создает другого актора, первый становится родителем(parent-ом).
Важно: акторы функционируют параллельно и ассинхронно обмениваются сообщениями.
Часть 2. Почтовые ящики, диспетчеры, маршрутизация, супервизор
Почтовый ящик – это неотъемлемый механизм взаимодействия между акторами, который позволяет принимать и извлекать сообщения. В классической модели акторов адресатом сообщения является сам актор-получатель. Т.е. для того, чтобы актор A мог отослать сообщение актору B, у актора A должна быть ссылка на актор B. Нет ссылки на актора-получателя — нет и возможности отослать ему сообщение. Если нужно выполнить рассылку 1:N, то у отправителя должны быть ссылки на всех получателей. Почтовые ящики бывают ограниченными и неограниченными, с приоритетами и без.
Диспетчеры
На каждую систему акторов приходится по одному диспетчеру, который отвечает за постановку сообщений в очередь, ведущую в почтовый ящик актора. Так же диспетчер даёт команду ящику изъять из очереди сообщение и передать его актору на обработку.
Маршрутизация
Маршрутизация позволяет за определенным именем актора скрыть целый пул акторов. Сообщения могут быть отправлены через маршрутизатор для более высокой эффективности их доставки. Маршрутизатор может использоваться внутри или снаружи субъекта и вы можете управлять маршрутизаторами самостоятельно или использовать автономный субъект маршрутизатора с возможностями конфигурации.
Супервизор
Супервизор – объект или процесс, который принимает решения при сбое. Каждый актор-родитель является супервизором своих детей. Решения при сбое:
1. Resume
2. Restart
3. Stop
4. Escalate
Каждое из приведенных понятий включает большой объем информации, который можно погуглить или почитать в стандартах. Беглый осмотр палитры акторов в LabVIEW мне показался скромным: всего 10 .vi, в то время как Akka-фреймворк даёт пользователю широкий спектр по управлению и действиями. Разберу пару тройку практических примеров(более крупных) для понимания достаточности представленной реализации.
Заключение
Модель акторов актуальна для задач типа Concurrency. Concurrency – это способность компонентов системы выполняться параллельно. Где такое встречается? Например, в приложениях с высоким количеством микросервисов(в частности компания Яндекс использует модель акторов в своих приложениях используя Akka Framework). В промышленности – это работа с большим количеством датчиков и оборудования параллельно и ассинхронно. Поскольку модель акторов имеет высокий порог вхождения, а разработка занимает больше времени, то применять этот framework следует с прицелом на будущее(повторяемость проектов и задач). Важным преимуществом модели акторов является повышенная отказоустойчивость программного обеспечения.
, там все это дело есть.