Connect |
Suspend |
Ready |
Finish |
Cancel |
|
|---|---|---|---|---|---|
Connecting |
Buffering / start_load |
||||
Buffering |
Playing / resume |
Closing |
|||
Playing |
Buffering / pause_play |
Closing |
|||
Closing |
Table 1.1: Representing the transitions between states in Figure 1.5.1
`Code Listing 1.3 <#cl1-3>`_ documents how to turn `Table 1.1 <#tbl1-1>`_ into executable code. To start, line 6 defines an enum type for the specific states for this FSM instance, and line 7 creates a preprocessor constant for the number of states. Recall from `Code Listing 1.1 <#cl1-1>`_ that states are, ultimately, integer types. The advantage of using an ``enum`` is that it allows us to refer to states by names (e.g., ``CONN`` for the ``Connecting`` state) instead of integers, which would be otherwise meaningless and likely to cause errors. Line 8 defines a constant for the number of events based on similar enum for events but defined elsewhere. Lines 11 – 17 encode the transitions defined in `Table 1.1 <#tbl1-1>`_. In the enum defined on line 6, the last value (``NST``) is used to indicate *no state*, meaning that there is no transition defined. These values in this two-dimensional array correspond to the blanks in the table. Lines 20 – 26 define a similar lookup table, but for the transition effects. Since effects are actions that do something, `Code Listing 1.1 <#cl1-1>`_ defined the ``action_t`` type as a function pointer; as a result, the empty values in the table are ``NULL`` pointers. .. _cl1-3: .. codeinclude:: IntroConcSys/CodeListing-1-3.c :linenos: true Note that `Code Listing 1.3 <#cl1-3>`_ declared both ``_transition`` (the transition table) and ``_effect`` (the effects table) as ``static``. This design choice helps to create a modular approach, as these tables will not be accessed directly outside of this file. `Code Listing 1.4 <#cl1-4>`_ shows how these tables will be accessed through the ``media_transition()`` function, also declared ``static`` in the same file. Given the FSM's current state, if the entry in the ``_transition`` table for the specified event is not defined, return -1 to indicate no transition should be taken. Otherwise, set the ``effect`` call-by-reference parameter to the appropriate function and return the next state. Note that, just like the ``_transition`` and ``_effect`` tables, the ``media_transition()`` function cannot be accessed outside the current file. The ``media_init()`` function provides the link. When a new instance of this FSM is needed, the controller can use this function to get a new ``fsm_t``, which contains a pointer to the ``media_transition()`` function. .. _cl1-4: .. codeinclude:: IntroConcSys/CodeListing-1-4.c :linenos: true Finally, `Code Listing 1.5 <#cl1-5>`_ shows how a controlling program would create a FSM instance and send it events. Since all of the information about the transitions and effects is encapsulated inside the FSM struct, the controller just needs to focus on the logic of which event to send to the FSM. Recall from `Code Listing 1.2 <#cl1-2>`_ that ``handle_event()`` passes the event through the FSM's ``fsm->transition`` function pointer to determine the state change and effect function. Since ``handle_event()`` ignores invalid transitions, sending the wrong event (such as on line 7) cannot cause an error in the FSM. .. _cl1-5: .. codeinclude:: IntroConcSys/CodeListing-1-5.c :linenos: true .. [#f4] There are more advanced state models, known as timed automata, that do explicitly incorporate time within their representation. However, we will not be using those models in this book. .. [#f5] The term state model is often used synonymously with finite-state machine or finite-state automata. Here, we are using the terms separately just to distinguish between the non-executable model and its executable implementation. .. avembed:: Exercises/IntroConcSys/StateModelSumm.html ka :module: StateModels :points: 1.0 :required: True :exer_opts: JXOP-debug=true&JOP-lang=en&JXOP-code=java :long_name: State model summary questions :threshold: 3