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>Chapter 6. Internals</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="pt01.html" title="Part I. User' guide"><link rel="prev" href="ch05.html" title="Chapter 5. Questions & Answers, tips"><link rel="next" href="ch06s02.html" title="Frontend / Backend interface"></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">Chapter 6. Internals</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch05.html">Prev</a> </td><th width="60%" align="center">Part I. User' guide</th><td width="20%" align="right"> <a accesskey="n" href="ch06s02.html">Next</a></td></tr></table><hr></div><div class="chapter" title="Chapter 6. Internals"><div class="titlepage"><div><div><h2 class="title"><a name="d0e3008"></a>Chapter 6. Internals</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="ch06.html#d0e3013">Backend: Run To Completion</a></span></dt><dt><span class="sect1"><a href="ch06s02.html">Frontend / Backend | |
| 4 | interface</a></span></dt><dt><span class="sect1"><a href="ch06s03.html"> Generated state ids </a></span></dt><dt><span class="sect1"><a href="ch06s04.html">Metaprogramming tools</a></span></dt></dl></div><p>This chapter describes the internal machinery of the back-end, which can be useful | |
| 5 | for UML experts but can be safely ignored for most users. For implementers, the | |
| 6 | interface between front- and back- end is also described in detail.</p><div class="sect1" title="Backend: Run To Completion"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e3013"></a><span class="command"><strong><a name="run-to-completion"></a></strong></span>Backend: Run To Completion</h2></div></div></div><p>The back-end implements the following run-to completion algorithm:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Check if one region of the concrete state machine is in a | |
| 7 | terminate or interrupt state. If yes, event processing is disabled | |
| 8 | while the condition lasts (forever for a terminate pseudo-state, | |
| 9 | while active for an interrupt pseudo-state).</p></li><li class="listitem"><p>If the message queue feature is enabled and if the state machine | |
| 10 | is already processing an event, push the currently processed event | |
| 11 | into the queue and end processing. Otherwise, remember that the | |
| 12 | state machine is now processing an event and continue.</p></li><li class="listitem"><p>If the state machine detected that no deferred event is used, skip | |
| 13 | this step. Otherwise, mark the first deferred event from the | |
| 14 | deferred queue as active.</p></li><li class="listitem"><p>Now start the core of event dispatching. If exception handling is | |
| 15 | activated, this will happen inside a try/catch block and the | |
| 16 | front-end <code class="code">exception_caught</code> is called if an exception | |
| 17 | occurs. </p></li><li class="listitem"><p>The event is now dispatched in turn to every region, in the order | |
| 18 | defined by the initial state front-end definition. This will, for | |
| 19 | every region, call the corresponding front-end transition definition | |
| 20 | (the "row" or "Row" of the transition table).</p></li><li class="listitem"><p>Without transition conflict, if for a given region a transition is | |
| 21 | possible, the guard condition is checked. If it returns | |
| 22 | <code class="code">true</code>, the transition processing continues and the | |
| 23 | current state's exit action is called, followed by the transition | |
| 24 | action behavior and the new active state's entry behavior.</p></li><li class="listitem"><p>With transition conflicts (several possible transitions, | |
| 25 | disambiguated by mutually exclusive guard conditions), the guard | |
| 26 | conditions are tried in reverse order of their transition definition | |
| 27 | in the transition table. The first one returning <code class="code">true</code> | |
| 28 | selects its transition. Note that this is not defined by the UML | |
| 29 | standard, which simply specifies that if the guard conditions are | |
| 30 | not mutually exclusive, the state machine is ill-formed and the | |
| 31 | behaviour undefined. Relying on this implementation-specific | |
| 32 | behaviour will make it harder for the developer to support another | |
| 33 | state machine framework.</p></li><li class="listitem"><p>If at least one region processes the event, this event is seen as | |
| 34 | having been accepted. If not, the library calls | |
| 35 | <code class="code">no_transition</code> on the state machine for every | |
| 36 | contained region.</p></li><li class="listitem"><p>If the currently active state is a submachine, the behaviour is | |
| 37 | slightly different. The UML standard specifies that internal | |
| 38 | transitions have to be tried first, so the event is first dispatched | |
| 39 | to the submachine. Only if the submachine does not accept the event | |
| 40 | are other (non internal) transitions tried.</p></li><li class="listitem"><p>This back-end supports simple states' and submachines' internal | |
| 41 | transitions. These are provided in the state's | |
| 42 | <code class="code">internal_transition_table</code> type. Transitions defined | |
| 43 | in this table are added at the end of the main state machine's | |
| 44 | transition table, but with a lesser priority than the submachine's | |
| 45 | transitions (defined in <code class="code">transition_table</code>). This means, | |
| 46 | for simple states, that these transitions have higher priority than | |
| 47 | non-internal transitions, conform to the UML standard which gives | |
| 48 | higher priority to deeper-level transitions. For submachines, this | |
| 49 | is a non-standard addition which can help make event processing | |
| 50 | faster by giving a chance to bypass subregion processing. With | |
| 51 | standard UML, one would need to add a subregion only to process | |
| 52 | these internal transitions, which would be slower.</p></li><li class="listitem"><p>After the dispatching itself, the deferred event marked in step 3 | |
| 53 | (if any) now gets a chance of processing.</p></li><li class="listitem"><p>Then, events queued in the message queue also get a dispatching | |
| 54 | chance</p></li><li class="listitem"><p>Finally, completion / anonymous transitions, if to be found in the | |
| 55 | transition table, also get their dispatching chance.</p></li></ul></div><p>This algorithm illustrates how the back-end configures itself at compile-time | |
| 56 | as much as possible. Every feature not found in a given state machine definition | |
| 57 | is deactivated and has therefore no runtime cost. Completion events, deferred | |
| 58 | events, terminate states, dispatching to several regions, internal transitions | |
| 59 | are all deactivated if not used. User configuration is only for exception | |
| 60 | handling and message queue necessary.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch05.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="pt01.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch06s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 5. Questions & Answers, tips </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Frontend / Backend | |
| 61 | interface</td></tr></table></div></body></html> |