projects / ceph.git / blame
| Commit | Line | Data |
|---|---|---|
| 7c673cae FG |
1 | <html><head> |
| 2 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | |
| 3 | <title>Frontend / Backend interface</title><link rel="stylesheet" href="boostbook.css" type="text/css"><meta name="generator" content="DocBook XSL-NS Stylesheets V1.75.2"><link rel="home" href="index.html" title="Meta State Machine (MSM)"><link rel="up" href="ch06.html" title="Chapter 6. Internals"><link rel="prev" href="ch06.html" title="Chapter 6. Internals"><link rel="next" href="ch06s03.html" title="Generated state ids"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Frontend / Backend | |
| 4 | interface</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch06.html">Prev</a> </td><th width="60%" align="center">Chapter 6. Internals</th><td width="20%" align="right"> <a accesskey="n" href="ch06s03.html">Next</a></td></tr></table><hr></div><div class="sect1" title="Frontend / Backend interface"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e3079"></a><span class="command"><strong><a name="internals-front-back-interface"></a></strong></span>Frontend / Backend | |
| 5 | interface</h2></div></div></div><p>The design of MSM tries to make front-ends and back-ends (later) to be as | |
| 6 | interchangeable as possible. Of course, no back-end will ever implement every | |
| 7 | feature defined by any possible front-end and inversely, but the goal is to make | |
| 8 | it as easy as possible to extend the current state of the library.</p><p>To achieve this, MSM divides the functionality between both sides: the | |
| 9 | front-end is a sort of user interface and is descriptive, the back-end | |
| 10 | implements the state machine engine.</p><p>MSM being based on a transition table, a concrete state machine (or a given | |
| 11 | front-end) must provide a transition_table. This transition table must be made | |
| 12 | of rows. And each row must tell what kind of transition it is and implement the | |
| 13 | calls to the actions and guards. A state machine must also define its regions | |
| 14 | (marked by initial states) And that is about the only constraints for | |
| 15 | front-ends. How the rows are described is implementer's choice. </p><p>Every row must provide:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>A <code class="code">Source</code> typedef indicating, well, the type of the source | |
| 16 | state.</p></li><li class="listitem"><p>A <code class="code">Target</code> typedef indicating, well, the type of the target | |
| 17 | state.</p></li><li class="listitem"><p>A <code class="code">Evt</code> typedef indicating the type of the event triggering | |
| 18 | the transition.</p></li><li class="listitem"><p>A <code class="code">row_type_tag</code> typedef indicating the type of the | |
| 19 | transition.</p></li><li class="listitem"><p>Rows having a type requiring transition actions must provide a static | |
| 20 | function <code class="code">action_call</code> with the following signature: <code class="code"> | |
| 21 | template <class Fsm,class SourceState,class TargetState,class | |
| 22 | AllStates> </code></p><p><code class="code">static void action_call (Fsm& fsm, Event const& evt, | |
| 23 | SourceState&, TargetState&, AllStates&) </code></p><p>The function gets as parameters the (back-end) state machine, the | |
| 24 | event, source and target states and a container (in the current | |
| 25 | back-end, a fusion::set) of all the states defined in the state machine. | |
| 26 | For example, as the back-end has the front-end as basic class, | |
| 27 | <code class="code">action_call</code> is simply defined as | |
| 28 | <code class="code">(fsm.*action)(evt)</code>.</p></li><li class="listitem"><p>Rows having a type requiring a guard must provide a static function | |
| 29 | <code class="code">guard_call</code> with the following signature:<code class="code"> </code></p><p><code class="code">template <class Fsm,class SourceState,class TargetState,class | |
| 30 | AllStates></code></p><p><code class="code">static bool guard_call (Fsm&, Event const&, | |
| 31 | SourceState&, TargetState&, AllStates&)</code></p></li><li class="listitem"><p>The possible transition (row) types are:</p><div class="itemizedlist"><ul class="itemizedlist" type="circle"><li class="listitem"><p>a_row_tag: a transition with actions and no guard</p></li><li class="listitem"><p>g_row_type: a transition with a guard and no | |
| 32 | actions</p></li><li class="listitem"><p>_row_tag: a transition without actions or guard</p></li><li class="listitem"><p>row_tag: a transition with guard and actions</p></li><li class="listitem"><p>a_irow_tag: an internal transition (defined inside the | |
| 33 | <code class="code">transition_table</code>) with actions</p></li><li class="listitem"><p>g_irow_tag: an internal transition (defined inside the | |
| 34 | <code class="code">transition_table</code>) with guard</p></li><li class="listitem"><p>irow_tag: an internal transition (defined inside the | |
| 35 | <code class="code">transition_table</code>) with actions and | |
| 36 | guards</p></li><li class="listitem"><p>_irow_tag: an internal transition (defined inside the | |
| 37 | <code class="code">transition_table</code>) without action or guard. | |
| 38 | Due to higher priority for internal transitions, this is | |
| 39 | equivalent to a "ignore event"</p></li><li class="listitem"><p>sm_a_i_row_tag: an internal transition (defined inside the | |
| 40 | <code class="code">internal_transition_table</code>) with | |
| 41 | actions</p></li><li class="listitem"><p>sm_g_i_row_tag: an internal transition (defined inside the | |
| 42 | <code class="code">internal_transition_table</code>) with | |
| 43 | guard</p></li><li class="listitem"><p>sm_i_row_tag: an internal transition (defined inside the | |
| 44 | <code class="code">internal_transition_table</code>) with actions and | |
| 45 | guards</p></li><li class="listitem"><p>sm__i_row_tag: an internal transition (defined inside the | |
| 46 | <code class="code">internal_transition_table</code>) without action | |
| 47 | or guard. Due to higher priority for internal transitions, | |
| 48 | this is quivalent to a "ignore event"</p></li></ul></div></li></ul></div><p>Furthermore, a front-end must provide the definition of states and state | |
| 49 | machines. State machine definitions must provide (the implementer is free to | |
| 50 | provide it or let it be done by every concrete state machine. Different MSM | |
| 51 | front-ends took one or the other approach):</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">initial_state</code>: This typedef can be a single state or | |
| 52 | a mpl container and provides the initial states defining one or | |
| 53 | several orthogonal regions.</p></li><li class="listitem"><p><code class="code">transition_table</code>: This typedef is a MPL sequence of | |
| 54 | transition rows.</p></li><li class="listitem"><p><code class="code">configuration</code>: this typedef is a MPL sequence of | |
| 55 | known types triggering special behavior in the back-end, for example | |
| 56 | if a concrete fsm requires a message queue or exception | |
| 57 | catching.</p></li></ul></div><p>States and state machines must both provide a (possibly empty) definition of:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">flag_list</code>: the flags being active when this state or | |
| 58 | state machine become the current state of the fsm.</p></li><li class="listitem"><p><code class="code">deferred_events</code>: events being automatically deferred | |
| 59 | when the state is the current state of the fsm.</p></li><li class="listitem"><p><code class="code">internal_transition_table</code>: the internal transitions | |
| 60 | of this state.</p></li><li class="listitem"><p><code class="code">on_entry</code> and <code class="code">on_exit</code> methods.</p></li></ul></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch06.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch06.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch06s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 6. Internals </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Generated state ids </td></tr></table></div></body></html> |