Повысить диаграммы состояний и мета государственная машина

видимо boost содержит две отдельные библиотеки для государственных машин: Statechart и Meta State Machine (МСМ). Слоганы дают очень похожие описания:

  • импульс.Statechart-произвольно сложные конечные автоматы могут быть реализованы в легко читаемом и поддерживаемом коде C++.
  • Meta State Machine - очень высокопроизводительная библиотека для выразительных конечных автоматов UML2.

вы знаете, каковы основные различия и каковы соображения при выборе между ними?

5 128
c++ boost-spirit state-machines boost-statechart boost-msm

5 ответов:

поскольку, по-видимому, есть большой интерес, позвольте мне дать свое (очевидно предвзятое) мнение, которое поэтому следует принять с солью:

  • МСМ намного быстрее
  • MSM не требует RTTI или что-нибудь виртуальное
  • MSM имеет более полную поддержку UML2 (например, внутренние переходы, UML-конформные ортогональные области)
  • MSM предлагает описательный язык (на самом деле несколько). Например, используя интерфейс eUML, переход можно описать как источник + событие [Guard] / действие = = цель
  • MSM заставит ваш компилятор страдать для больших государственных машин, поэтому вам понадобится довольно недавний компилятор (g++ >= 4.x, VC >= 9)

вы можете сделать себе лучшее мнение, глядя на комментарии, опубликованные во время обзора MSM. Эта тема много обсуждалась в списке разработчиков.

101

С Boost.Диаграммы состояний можно распределить планировка (т. е. состояния, переходы) вашего конечного автомата по нескольким единицам перевода (cpp-файлы) способами, которые вы не можете использовать с MSM. Это позволяет сделать реализация больших FSMs более ремонтопригодна и получить гораздо более быструю компиляцию, чем с MSM.

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

предполагая, что умеренно сложный FSM реализован с помощью Boost.Statechart, вот несколько номеров на стадионе:

  • большинство текущее оборудование ПК легко справится с > 100'000 событиями в секунду
  • даже очень оборудование с ограниченными ресурсами сможет обрабатывать несколько сотен событий в секунду.

Что касается загрузки процессора, если количество событий для обработки намного меньше, чем эти цифры, повысьте.Накладные расходы Statechart по сравнению с MSM почти наверняка не будут заметны. Если число намного выше, вам определенно лучше с MSM.

более подробно информацию о компромиссах производительности / масштабируемости можно найти здесь: http://www.boost.org/doc/libs/1_45_0/libs/statechart/doc/performance.html

100

при кодировании моей собственной реализации PPP я использовал Statechart по трем причинам: 1) Statechart проще и имеет более четкую документацию; 2) мне очень не нравится UML:)

Boost docs говорят, что MSM по крайней мере в 20 раз быстрее, но компилируется довольно медленно для больших FSM.

9

некоторое время назад я начал с Statechart и перешел на MSM, потому что его было проще использовать в сочетании с asio из одного потока. Мне не удалось связать Statechart и его многопоточность с использованием asio - это, вероятно, было какое-то непонимание новичком Statechart с моей стороны. Я обнаружил, что MSM было проще в использовании, поскольку он не обращался к многопоточности.

3

в ответ на позднюю запись Тима в обсуждении (которая также касается одного из самых ранних комментариев от Льва).

как один из тех, кто выступал за отделение выхода от деструкторов в statechart (аргумент, основанный на реальном случае использования, о взаимодействии с реальным миром, т. е. ввод-вывод), когда он был представлен для повышения, Я согласен, что могут быть проблемы с размещением логики выхода в деструкторах. Дэвид Абрахамс неудивительно сделал убедительные аргументы относительно безопасности исключений. По этим причинам Statechart не требует, чтобы вы помещали логику в деструкторы - но это позволяет вам - с обычным советом.

логика, которая должна выполняться только как часть перехода из состояния (а не уничтожение объекта statechart в целом), может (и должна, если есть также очистка ресурсов) быть разделена на отдельное действие exit ().

для "тонкого" состояния без активного состояния (ресурсов), просто действия входа/выхода для выполнения, вы можете выполнить их действия в ctor и d'Tor и убедитесь, что конструктор и деструктор не бросают. Для них нет причин - нет состояния для выполнения RAII - нет никакого зла в том, что обработка ошибок в этих местах вызывает соответствующие события. Возможно, Вам все же придется рассмотреть, хотите ли вы, чтобы действия выхода, которые изменяют внешнее состояние, выполнялись при уничтожении конечного автомата... и поместите их в действие выхода, если вы не хотите, чтобы они произошли в этом случае...

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

Это все хорошо документально-я предлагаю вам прочитать документы и попробовать его. Я предлагаю вам использовать деструкторы для очистки " программных ресурсов "и действий выхода для выполнения"реальных действий выхода".

стоит отметить, что распространение исключений является немного проблемой во всех средах, управляемых событиями, а не только в диаграммах состояния. Лучше всего рассуждать и включать ошибки / ошибки в свой дизайн диаграммы состояния, и если и только если вы не можете обрабатывать их другим способом, прибегайте к отображению исключений. Хотя бы те работает на меня-ymmmv....

2