부스트 상태 차트와 메타 상태 머신

분명히 boost에는 상태 시스템에 대한 두 개의 별도 라이브러리 인 Statechart 와 Meta State Machine (MSM)이 포함되어 있습니다. 태그 라인은 매우 유사한 설명을 제공합니다.

• Boost.Statechart-임의로 복잡한 유한 상태 머신은 쉽게 읽고 유지 관리가 가능한 C ++ 코드로 구현할 수 있습니다.
• Meta State Machine-표현형 UML2 유한 상태 머신을위한 고성능 라이브러리입니다.

주요 차이점이 무엇이고 두 가지 중에서 선택할 때 고려해야 할 사항이 있습니까?

많은 관심이있는 것 같아서, (분명히 편향된) 의견을 제시 할 수있게 해주십시오.

• MSM이 훨씬 빠릅니다
• MSM은 RTTI 또는 가상의 것을 요구하지 않습니다
• MSM은보다 완벽한 UML2 지원 (예 : 내부 전환, UML 준수 직교 영역)
• MSM은 설명 언어 (실제로는 여러 언어)를 제공합니다. 예를 들어, eUML 프런트 엔드를 사용하면 전환이 소스 + 이벤트 [가드] / 동작 == 대상으로 설명 될 수 있습니다.
• MSM은 컴파일러가 더 큰 상태 머신으로 인해 어려움을 겪을 수 있도록 최신 컴파일러가 필요합니다 (g ++> = 4.x, VC> = 9)

MSM 검토 중에 게시 된 의견을 찾아보다 나은 의견을 제시 할 수 있습니다. 이 주제는 개발자 목록에서 많이 논의되었습니다.

Christophe가 이미 언급했듯이 두 라이브러리의 주요 차이점 중 하나는 런타임 성능입니다. MSM은 아마도 최고의 이점을 제공하지만 Statechart는 더 나은 확장 성을 위해 메모리와 프로세서주기를 의식적으로 교환합니다.

Boost.Statechart를 사용하면 상태 시스템 의 레이아웃 (예 : 상태, 전환)을 MSM에서 할 수없는 방식으로 여러 변환 단위 (cpp 파일)에 분산시킬 수 있습니다. 이를 통해 대규모 FSM 구현을보다 유지 관리하고 MSM보다 훨씬 빠르게 컴파일 할 수 있습니다.

상태 차트의 성능 오버 헤드가 MSM과 비교하여 실제로 응용 프로그램에 중요한지 여부는 앱이 초당 처리해야하는 이벤트 수를 스스로에게 묻는 경우 종종 대답하기 쉽습니다.

Boost.Statechart로 구현 된 약간 복잡한 FSM을 가정하면 몇 가지 야구장 번호가 있습니다.

• 최신 PC 하드웨어는 초당 100,000 개 이상의 이벤트에 쉽게 대처할 수 있습니다.
• 리소스가 매우 제한된 하드웨어 라도 초당 수백 개의 이벤트를 처리 할 수 ​​있습니다.

CPU로드와 관련하여 처리 할 이벤트 수가이 수보다 훨씬 적 으면 MSM에 비해 Boost.Statechart 오버 헤드가 거의 눈에 띄지 않습니다. 숫자가 훨씬 높으면 MSM을 사용하는 것이 좋습니다.

성능 / 확장 성 트레이드 오프에 대한 자세한 내용은 여기를 참조 하십시오. http://www.boost.org/doc/libs/1_45_0/libs/statechart/doc/performance.html

내 자신의 PPP 구현을 코딩하는 동안 나는 세 가지 이유로 Statechart를 사용했습니다. 1) Statechart는 더 간단하고 더 명확한 문서를 가지고 있습니다. 2) 나는 UML을 정말로 싫어한다 :)

부스트 문서에 따르면 MSM은 최소 20 배 빠르지 만 큰 FSM의 경우 컴파일 속도가 느립니다.

얼마 전에 Statechart로 시작하여 단일 스레드의 asio와 함께 사용하기가 쉽기 때문에 MSM으로 옮겼습니다. 필자는 asio를 사용하여 Statechart와 멀티 스레딩 기능을 메쉬 할 수 없었습니다. MSM은 멀티 스레딩을 처리하지 않으므로 사용하기가 더 쉽다는 것을 알았습니다.

토론에 대한 Tim의 늦은 입장에 대한 답변으로 (Lev의 초기 의견 중 하나도 언급).

부스트에 제출되었을 때 상태 차트 (실제 사용 사례를 기반으로 한 인수, 실제 세계와의 상호 작용에 대한 인수)에 대한 인수와의 분리를 주장한 사람들 중 하나로서 Boost에 제출했을 때 나가는 데 문제가있을 수 있음에 동의합니다 소멸자의 논리. 데이비드 아브라함은 당연히 예외 안전에 관한 설득력있는 주장을했습니다. 이러한 이유로 Statechart는 소멸자에 논리를 넣을 것을 요구하지는 않지만 일반적인 조언으로 할 수 있습니다.

상태에서 전이의 일부로 만 실행되는 논리 (상태 차트 개체 전체를 파괴하지 않음)는 별도의 exit () 작업으로 분리 될 수 있습니다 (자원 정리가 필요한 경우).

활성 상태 (자원)가없는 "얇은"상태의 경우 수행 할 시작 / 종료 조치 만 ctor 및 d' tor에서 해당 조치를 수행하고 생성자와 소멸자가 던지지 않도록 할 수 있습니다. RAII를 수행 할 상태가없는 이유는 없습니다. 이러한 장소에서 오류 처리를 수행하여 적절한 이벤트를 발생시키는 데 악은 없습니다. 상태 머신 파괴시 외부 상태를 변경하는 종료 조치를 원하는지 여부를 고려해야 하고이 경우에 발생하지 않으려면 종료 조치를 취해야합니다 ...

상태 차트는 활성화를 객체의 인스턴스화로 활성화하므로 생성자가 수행 할 실제 작업 / 활성화 / 인스턴스화가 있고 실패 할 수있는 경우 상태를 입력 할 수없는 경우 상태 차트는 예외를 행사. 이것은 스택이 호출 스택 기반 호출 모델에 대해 풀린 방식과 유사하게 예외 이벤트를 처리하는 외부 상태를 찾는 상태 계층 구조를 작동시키는 방식으로 처리됩니다.

이것은 모두 잘 문서화되어 있습니다. 문서를 읽고 사용해보십시오. 소멸자를 사용하여 "소프트웨어 리소스"를 정리하고 작업을 종료하여 "실제 종료 작업"을 수행하는 것이 좋습니다.

예외 전파는 상태 차트뿐만 아니라 모든 이벤트 중심 환경에서 약간의 문제입니다. 상태 차트 디자인에 오류 / 오류를 추론하고 포함시키는 것이 가장 좋으며 예외 매핑에 대한 다른 방법으로 오류를 처리 할 수없는 경우에만 가능합니다. 적어도 그것은 저에게 효과적입니다-ymmmv ....