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>