Vit (24.05.2009 22:36, просмотров: 180) ответил Evgeny_CD на Интересно, а так state machines кто-то делает?Не очень понимаю что зачем. *Имя машины, равно задачи или процесса, ИМХО, относится к вопросам отладки и документирования. Во время работы может пригодиться при формировании сообщений (диагностических и/или о вмешательствах).
*Число состояний интересует только при поиске наиболее продолжительных исполняющих участков кода, для оценки базового кода ошибки при унифицированной системе контроля ошибок, ну и для документирования.
*переменная, описывающая текущее состояние - ИМХО, нечто не очень осязаемое. Известны вариации на тему структуры, содержащей индекс состояния, время входа и время выхода (по системному таймеру), но оно очень привязано к конкретной архитектуре.
* одна функция - одно состояние? Накладные великоваты по ОЗУ - память жрут и статические переменные и стеки (в зависимости от архитектуры доля разная). Дробление должно быть оправданно мелким. А непосредственное "внешнее" управление разрушает целостность логического восприятия задачи (как более крупной единицы, чем функция).
* глобальные переменные машины это, ИМХО, в первую очередь вопрос безопасности, во-вторую - вопрос описания/структурирования данных. Учитывать глобальные переменные, конечно, нужно, но не маниакально;), ну и нельзя забывать, что с ними обычно ухудшается модульность программного проекта.
*"частично доступные для отдельных состояний переменные" вне моего понимания.
Делаем глобальный массив - указатели на функции-состояния. № элемента = номер состояния. - вот тут без БД, ИМХО, начнётся полный пипец, а как привязать БД к отладчику я, например, не знаю.
Делаем гипервизор. Который переключает состояния. Берет переменную-состояние и делает переход по таблице. не называл бы это гипервизором. У меня такого рода шедулеры используются. Только я держу массив списков указателей на функции и рулю с помощью специальных индексов. Иногда эффективное решение, но очень специфично, особенно в отладке.
Внутри тела каждой функции делаем то, что должны делать, анализируем переменные, и возвращяем новое состояние машины. А гипервизор делает этот скачек. При использовании статических сопрограмм использую возврат номера состояния (пишу его вручную - оно не привязано к __LINE__) - что ещё нужно?
Если проявить немного фантазии, то видно, что количество ошибок можно резко уменьшить. Извините, но одна из прелестей статических сопрограмм и, думаю, задач или потоков в других архитектурах, в том, что достаточно крупная "нарезка" это и модульность и алгоритмически законченные блоки - они понятны не только чистым программистам, но и системным проектировщикам - их блохи не интересуют. А количество ошибок определяется не мощностью контролирующего компьютера, а тем, кто им осознанно рулит.
Есть, например, описание протокола. С описанием машин, состояний и перменных. - например у меня реализация многохостового Modbus-Slave(serial) сделана путём перерисовывания в программу из доки машин состояния с теми же именами состояний и признаков. Ничего особенного, ИМХО.
Вполне можно сделать иерархические FSM. Просветите, плз, что это