Impulsar el Statechart vs Meta de la Máquina de Estado

Como Christophe ya ha mencionado, una de las diferencias clave entre las dos bibliotecas es el rendimiento en tiempo de ejecución. Mientras que MSM probablemente ofrece lo mejor que puede obtener aquí, Statechart negocia conscientemente los ciclos de memoria y procesador hacia una mejor escalabilidad.

Con Boost.Statechart puede distribuir el layout (es decir, estados, transiciones) de su máquina de estados sobre varias unidades de traducción (archivos cpp) de maneras que no puede con MSM. Esto le permite realizar la implementación de los FSM grandes son más fáciles de mantener y obtienen una compilación mucho más rápida que con MSM.

Si la sobrecarga de rendimiento de Statechart en comparación con MSM será realmente significativa para su aplicación a menudo es bastante fácil de responder cuando se pregunta cuántos eventos tendrá que procesar su aplicación por segundo.

Asumiendo un FSM moderadamente complejo implementado con Boost.Statechart, aquí hay algunos números de estadio:

• La mayoría del hardware de PC actual hará frente fácilmente con >100 ' 000 eventos por segundo
• Incluso muy el hardware con recursos limitados será capaz de procesar unos pocos cientos de eventos por segundo.

En cuanto a la carga de CPU, si el número de eventos a procesar es mucho menor que estos números, Boost.La sobrecarga de Statechart en comparación con MSM casi seguramente no se notará. Si el número es mucho más alto, definitivamente estás mejor con MSM.

Se puede encontrar información más detallada sobre las compensaciones rendimiento / escalabilidad aqui: http://www.boost.org/doc/libs/1_45_0/libs/statechart/doc/performance.html

Mientras codificaba mi propia implementación PPP utilicé Statechart por tres razones: 1) Statechart es más simple y tiene documentación más clara; 2) Realmente no me gusta UML :)

Los documentos de Boost dicen que MSM es al menos 20 veces más rápido, pero compila bastante lento para FSM grandes.

Hace algún tiempo comencé con Statechart y me moví a MSM porque era más fácil de usar junto con asio desde un solo hilo. No me las arreglé para malla Statechart y sus capacidades de multihilo con mi uso de asio - era probable que algún tipo de incomprensión novato de Statechart de mi parte. Descubrí que MSM era más fácil de usar, ya que no abordaba el multihilo.

En respuesta a la entrada tardía de Tim a la discusión (que también aborda uno de los comentarios muy tempranos de Lev).

Como uno de los que argumentó por la separación de salida de los destructores en statechart (argumento basado en un caso de uso real, sobre la interacción con el mundo real, es decir, E/S) camino atrás cuando se presentó a Boost estoy de acuerdo en que puede haber problemas en poner la lógica de salida en los destructores. Como era de esperar, David Abrahams también hizo argumentos persuasivos con respecto a la seguridad de las excepciones. Para esas razones Statechart no requiere que usted ponga lógica en destructores-pero le permite-con el consejo habitual.

La lógica que solo debería ejecutarse como parte de una transición fuera de un estado (no la destrucción del objeto statechart como un todo) puede (y debería si también hay que hacer limpieza de recursos) ser separada en una acción exit() separada.

Para un estado "delgado" sin estado activo (recursos), solo acciones de entrada / salida a realizar, puede realizar esas acciones en ctor y D'tor y asegúrate de que el constructor y el destructor no lanzan. No hay razón para que - no hay estado para realizar RAII en-no hay mal en que el manejo de errores en estos lugares plantean eventos apropiados. Sin embargo, es posible que aún deba considerar si desea que las acciones de salida que alteren el estado externo se ejecuten en la destrucción de máquinas de estado... y ponlos en acción de salida si no quieres que ocurran en este caso...

Statechart modela la activación como instanciación de un objeto, por lo que si su constructor tiene trabajo/activación/instanciación real que hacer y si es capaz de fallar de tal manera que el estado no se puede ingresar Statechart lo soporta al darle la capacidad de mapear una excepción a un evento. Esto se maneja de una manera que funciona en la jerarquía de estados buscando un estado externo que maneje el evento de excepción, análogo a la forma en que la pila se habría desenrollado para un modelo de invocación basado en la pila de llamadas.

Todo esto está bien documentado-te sugiero que leas los médicos y pruébalo. Sugiero que use destructores para limpiar " recursos de software "y acciones de salida para realizar"acciones de salida del mundo real".

Vale la pena señalar que la propagación de excepciones es un pequeño problema en todos los entornos impulsados por eventos, no solo en statecharts. Es mejor razonar e incluir fallas / errores en su diseño de statechart y si y solo si no puede manejarlos de otra manera, recurra al mapeo de excepciones. Al menos eso funciona para mí - ymmmv....