Differences

This shows you the differences between two versions of the page.

--- wiki:news:27okt2012 [2012/11/19 19:23] – [Points to consider with regions] pmueller
+++ wiki:news:27okt2012 [2013/08/12 15:11] – [How regions are implemented] pmueller
@@ Line 1: / Line 1: @@
-====== New beta version supporting regions ======
+====== Generate code from state machines with regions ======
 In state diagrams usually only one state is active at a time. In UML state diagrams regions also allow to model concurrency - i.e. more than one state is active at a time (AND states).
@@ Line 48: / Line 48: @@
   * For each region an own function is generated. Its name is automatically derived from the region name.
   * If a state contains several regions they are called one after the other (in alphabetical order). If the event sent to the state machine was processed in one of the regions no further event handling happens. Otherwise the event is processed in the parent state. This is similar to the event handling of normal hierarchical state machines.
-  * To maintain consistency during execution of machine code a copy of the instance data is created at the beginning of the state machine code. All tests are performed on the original instance data. All changes are done on the copy. This ensures that all regions "see" the same situation when running. At the end of the machine code the modified instance data is copied back to the original data. FIXME Note: this is not yet available in the C++ backend.
+  * To maintain consistency during execution of machine code a copy of the instance data is created at the beginning of the state machine code. All tests are performed on the original instance data. All changes are done on the copy. This ensures that all regions "see" the same situation when running. At the end of the machine code the modified instance data is copied back to the original data.  <del>Note: this is not yet available in the C++ backend.</del>
@@ Line 151: / Line 151: @@
 ** Regions must work on the same instance data **
-State diagrams follow the //run-to-completion// concept: Transitions that fire are fully executed and the state machine reaches a stable state configuration until it returns and can respond to the next event. To ensure this a copy of the instance data is kept and state changes are only performed on that copy. In practice this means that changes in one region does not influence other regions. Look into the following example. If the event  ''evClosed'' is sent region ''ValveA'' and ''ValveB'' change state. But there is no state change in region ''Motor'' at the same time. The reason is that the transition from ''Stop'' → ''Run'' was not triggered at the beginning of the machine execution. This behavior ensures that the result of a machine execution step is 100% predictable and e.g. not independent of the execution order of regions.
+State diagrams follow the //run-to-completion// concept: Transitions that fire are fully executed and the state machine reaches a stable state configuration until it returns and can respond to the next event. To ensure this a copy of the instance data is kept and state changes are only performed on that copy. In practice this means that changes in one region does not influence other regions. Look into the following figure below.
+  * If the event  ''evClosed'' is sent region ''ValveA'' and ''ValveB'' change state.
+  * But there is no state change in region ''Motor'' at the same time. The reason is that the transition from ''Stop'' → ''Run'' was not triggered at the beginning of the machine execution.
+  * This behavior ensures that the result of a machine execution step is 100% predictable and e.g. not dependent of the execution order of the regions.
+  * But on the other side it means that a second run of the machine is required to reach state ''MachineRun''. I.e. the region ''Motor'' is always one cycle behind the ''Valve'' regions.
 {{ :wiki:news:problems_with_regions_2.png?nolink | Problems with regions II}}