![]() ![]() BRAHMS
User Guide » Developing Processes » Advanced Topics » Life Cycle
This documentation is offline - click here to go online
Index | Search: Go online to use Search
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
OverviewThe basic, linear, Life Cycle was described previously. Here, we consider the issues that emerge when we engage more advanced modes of operation. In particular, we consider the sub-phases of the Life Cycle in detail, and see what their significance is. The basic Life Cycle is repeated below, for convenience. We have filled in the Summary column with the actions that a more comprehensive Process might take.
Run StateIn Run Phase, we describe the Process as being in one of the following Run States: STOP, PAUSE or PLAY. Four of the five Run Phase events move the process between these states, as shown in the table below. Movement between these states is key to supporting advanced modes of execution (sub-sections, below).
More advanced processes may need to take action during these transitions, and how to choose these actions is the subject of this section. Loosely, a Process in each of these states should have less or more of its external interactions (interactions with things other than the Framework, e.g. the OS or any attached hardware) in a ready state, as shown in the table below.
In STOP, therefore, a Process should consist of just an in-memory representation of its StateML, along with internal (Framework) interactions such as handles to input and output Ports. Pause-Resume ExecutionThe user may wish to pause processing during an execution, e.g. to check or record the state of some part of the system, or something attached to it, or simply to gaze in wonder at the beautiful data in their GUI. When the Execution is paused, its superficial state (everything the Framework is aware of) does not need to change. However, some Processes that have external interactions may need to pause those interactions whilst the System is paused. In particular, any Process that has a real-time interaction (particularly with a physical system) will want to suspend that interaction cleanly whilst the System is paused. Note that the System may be paused for any length of Wall Clock time. The possibility of Pause and Resume introduces the following modification to the Life Cycle.
This Resume-Pause Cycle (Resume, Service, ..., Service, Pause) may occur multiple times (including zero) within Run Phase, and the System may spend arbitrary lengths of time in the Run State PAUSE. The Process should pause real-time interactions cleanly as it is moved into PAUSE and resume (or start) them cleanly as it is moved into PLAY. However, it should do nothing else - these transitions are intended to support real-time interactions only. If other processing is done, here, this will impact on the time taken for the whole System to move between PAUSE and RUN states; this may annoy the user, but more seriously may adversely affect the operation of Peer Processes that rely on a fairly rapid transition. To be clear, a Process that does not have external real-time interactions (the vast majority of Processes) can safely ignore these two transition events. Stop-Play Execution and Dynamic Load BalancingThe user may wish to stop processing during an execution, e.g. to store the System to disk for later revival. In this case, all Processes will be asked to When a System is revived (restarted by the user), note that it may be restarted on a different hardware system (even, potentially, on a different platform). This underlines why OS resources, as well as other external interactions, must be released in the meantime. In addition, if a System is undergoing Dynamic Load Balancing, individual Processes may be moved into STOP, asked to Note that the most common reason for moving into STOP is that the System has finished execution. Whilst this is the most common, it does not define what you should do - assume you are moving into STOP for one of the above reasons, and you will be doing the right thing anyway. Whilst in PAUSE, the System can be described as "ready to run", in STOP it can be described as "ready to get ready to run". That is, it is assumed that moving between STOP and PLAY may take an arbitrary amount of Wall Clock time, and a Process need not feel embarassed about this. Conversely, the state STOP can be described as "ready to
We can see that only Processes that support EVENT_STATE_GET can actually undergo Stop-Play execution or Dynamic Load Balancing. Implementing EVENT_STATE_GET is unnecessary if you do not want to support these modes of operation; conversely, not implementing it will mean your Process cannot support these modes, at least not without further development work. Process and Engine InteractionsHere, we show Process and Engine proceeding through the Life Cycle in parallel. This section tells you less about the Process, and will be of more use to anybody wishing to understand the operation of the Engine. Note that we show only the everyday Life Cycle, without the nuances introduced above for more complex modes of operation. Process Life CycleThis is the Life Cycle of an Execution from the point of view of a Process, which runs in a Worker Thread. This Worker Thread may change under some conditions - see Thread Sensitivity. In brief, a BRAHMS process must do three things, as follows.
Engine Life CycleThis is the Life Cycle of an Execution from the point of view of the Engine, which runs in the Caller Thread. Pre-amble
Init PhaseNotes
CREATE
PRECONNECT
CONNECTUntil all inputs have been seen:
POSTCONNECT
START LOGS
Init PhaseREAD XML
SOCIALIZE
CREATEFor each Process:
PRECONNECTFor each Process:
CONNECTIf at any run through the following loop, no progress occurs, Until all Processes have seen all inputs:
POSTCONNECT
START LOGSFor each Process:
Run Phase
Notes
Until stopped (Soft Stop or Hard Stop):
Run PhaseCALLER THREADUntil all worker threads have terminated:
WORKER THREAD(S)
Until Soft Stop (usually, reached Execution Stop Time) or Hard Stop:
Term PhaseSTATE
LOGS
Post-amble
Term PhaseSTATEFor each Process:
LOGSFor each output of each Process:
For each Process:
REPORT
Post-amble
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This is a documentation page for the BRAHMS Modular Execution (Simulation) Framework. For details of licensing and distribution, please click here. To advise of an error or omission, please click here. |