Про State machine

[AndreyDmitriev]

AndreyDmitriev, я использую в основном шаблон "Queued Message Handler" и считаю его намного удобнее остальных конструкций конечных автоматов. И, конечно, основным плюсом здесь является отзывчивость и независимость UI от остального кода. А шаблон из "State Machine Fundamentals" неудачен даже для новичков, которые, столкнувшись с вышеописанными "граблями" такого подхода, всё-таки переходят на шаблон "Queued Message Handler" (и вот тому подтверждение). Вот вы пишете, что ничего плохого нет, когда эвент стоит в кейс-структуре. Ну, чёрт с ним, с GUI - панель заблокируется, пользователь потерпит-подождёт секунд 10

Мы всё же немножко о разных вещах говорим. У каждого шаблона есть свои области применимости. Отзывчивость UI никак не связана с шаблоном, она связана с тем, как Event структура используется в контексте шаблона. Опять же "потерпит-подождёт" не должно быть связано с тем, что так было удобно программисту, либо он использовал неверный шаблон или подход. "Queued Message Handler" в основном используется тогда, когда более-менее сложная логика (это может быть железка, но не обязательно) управляется внешними воздействиями пользователя - тут мы хотим отделить логику от интефейса и этот шаблон позволяет раскинуть это на два цикла, при этом один не будет тормозить другой, а сообщения будут складываться в очередь и не теряться. "State Machine Fundamentals" применяется тогда, когда мне не нужно отделять UI, но сложность логики требует State machine. Ну, вот к примеру, у меня сложный диалог - там одни контролы включаются в зависимости от состояния других, идёт обработка событий как от кнопок, так и от меню, можно переключить миллиметры в дюймы, одновременно происходит индикация состояния - всё это завязано на интерфейс, однако простой Event структуры мне уже недостаточно (либо её придётся под завязку набить кодом, обвесив динамическими событиями), а Producer-Сonsumer мне для этого ещё не нужен - вот тут и делается простой автомат, где Event структура становится частью этого автомата и туда выносится часть кода из Event структуры (я иногда размещаю Event структуру рядом с автоматом - так бывает удобнее). Event структура, являющаяся частью конечного автомата, не вызывает никакого торможения при условии, что в каждом состоянии этого автомата мы находимся время, сильно меньшее чем время реакции пользователя.

[Blackman]

...Event структура, являющаяся частью конечного автомата, не вызывает никакого торможения при условии, что в каждом состоянии этого автомата мы находимся время, сильно меньшее чем время реакции пользователя.

Андрей, Вы абсолютно правы, что при интенсивной работе с UI шаблоны типа FSM более подходящий выбор, чем QMH.
Вы могли бы дать более подробные комментарии к последнему предложению из Вашего сообщения?
Мне кажется, что это может быть понято как исключение возможности применения состояний требующих временных ресурсов.
Что можно делать в этом случае, Вы рассказали здесь http://labviewportal.org/viewtopic.php? ... =15#p70036

P.S. Я не корректно применил аббревиатуру QMH - Queued Message Handler к шаблону Producer-Consumer. QMH был назван шаблон типа FSM в котором вместо Enum используется массив строк. Sorry)
LabVIEW for Everyone: Graphical Programming Made Easy and Fun (3rd Edition) 2006
http://flylib.com/books/en/3.352.1.165/1/

[dadreamer]

AndreyDmitriev, Blackman, в таком случае нужно все времязатратные операции вынести в отдельный цикл, оставив в SM только работу с (G)UI. Это будет в каком-то роде гибрид "State Machine Fundamentals" и "Queued Message Handler".

[AndreyDmitriev]

...Event структура, являющаяся частью конечного автомата, не вызывает никакого торможения при условии, что в каждом состоянии этого автомата мы находимся время, сильно меньшее чем время реакции пользователя.

Андрей, Вы абсолютно правы, что при интенсивной работе с UI шаблоны типа FSM более подходящий выбор, чем QMH.
Вы могли бы дать более подробные комментарии к последнему предложению из Вашего сообщения?

Ну тут особо комментировать нечего - выше уже более чем достаточно информации.
В общем случае, если в коде с участием Event структуры выполняется "времязатратная" операция, и на время выполнения этого участка мы хотим сохранить полный контроль над интерфейсом и не блокировать его, то код надо вынести из цикла обработки событий UI - тут без вариантов. Если этого не делать, то надо явно блокировать UI (с показом песочных часов, прогресс индикаторами, и т.д.). Особняком стоит решение с выдачей модального окна прогресса выполнения. Это окно само по себе будет блокировать интерфейс вызывающего кода (тут уже без разницы, вызываете ли вы его прямо из структуры, или из отдельного цикла). Так устроен диалог, который LabVIEW показвает при сборке приложения - пользователь может остановить действие, либо вызвать справку-помощь, но это все действия, которые ему доступны - продолжать работать в LabVIEW пользователь не может до тех пор, пока не завершится генерация приложения.

Вообще проще посмотреть как инженеры NI используют State Machine с Event структурой. Откройте, скажем, %ProgramFiles%\National Instruments\LabVIEW 2015\resource\dialog\NewProjectWizard\NewProjectDialog.vi - там как раз этот случай.

[Kosist]

Недавно наткнулся на эту тему, и решил - с вашего позволения - вставить и свои пять копеек.
Я нашел JKI State Machine удобной для создания виаек для несложного анализа файлов, тестирования железа, и т.д. Т.е. если нужно сделать более-менее нормальную и удобную виайку, скажем, для анализа файлов-отчетов (выбрать директорию, загрузить файлы, проанализировать, создать мини-отчет), в таком случае JKI State Machine, как по мне, довольно удобная. Т.к. там сразу уже есть секция для инициализации кластера, реализованная стейт машина, выполнение серии стейтов, обработчик ошибок. Можно, конечно, создать свое подобие такого шаблона, но лень - ведь уже есть что-то готовое.
Вот и юзаю, если нужно...
Но, для более сложных виаек, где выполняется много разных действий, тогда уже приходится делать Producer-Consumer, и т.д.; по причинам, описанным выше тоже в этом посте.
В последнее время хочется поклацать их State Machine Objects - выглядит более интерестно, напоминает Actor Framework, но, кажется, попроще. Но все как-то руки не доходят, нет подходящего приложения для этого паттерна...
Хотя в их вебинаре о HAL, приложение было сделано как раз при помощи State Machine Objects тоже...

[AlexanderKonoval]

Как по мне, лучшая машина состояний - это ивент структура, работающая на динамических ивентах. На каждую железку - свой отдельный цикл+очередь команд от машины состояний.
Итого циклы железок или программных модулей генерят ивенты, машина состояний ивенты обрабатывает и отправляет в нужные очереди нужные команды. Модули команды выполняют и генерят новые ивенты.
Динамические ивенты особо удобны тем, что внутри ивента может быть любой тип данных. Не надо извращаться со строками, вариантами, парсить потом всё это. Ставишь удобные кластеры и работаешь.

хотя такая архитектура увеличивает время разработки, зато она просто-таки феноменально гибкая.