Dirty node conditional branching

propagate events for dirty nodes only

Introduction

The goal is to only let the execution path propagate if a node marks itself as being dirty.

Sometimes it is useful to only let the event wave progress if the current node marks itself as being dirty. The intention is to remove the burden from the node developer to check state of parent nodes for a valid change.

We want the framework to handle the conditional execution of branches by simply arresting the event notification wave on that branch.

For example a level monitor reports the state of a breach as a boolean value. The SEP will swallow the event wave if the level node OnEvent return a value of false. Any child nodes would only receive OnEvent notifications when the level is breached and a value of true returned.

An OnEvent method with a boolean return type is monitored as a dirty status flag by Fluxtion with the following rules:

  • A true value marks the node as dirty and the event wave propagates.

  • A false value swallows the event wave and no child OnEvent methods are invoked.

  • A void return from OnEvent is presumed as a persistent value of true which will always propagate events.

  • If a child has multiple parents any parent change propagates the event wave i.e. an "or rule" is applied.

Dirty filtering support can be globally toggled on or off using the supportDirtyFiltering property in the SEPConfig builder.

Example

We create a node, DirtyNode, that reports its dirty status with the return of its OnEvent method. Three DirtyNode's are created and each DirtyNode listens to one of two event handlers. The three DirtyNodes are aggregated in a class, DirtyNodeAggregator. The OnEvent method publishDirty(), will be protected by guard conditions that check at least one parent is dirty before being invoked.

The code for the example is located here.

The DirtyNode

DirtyNodeAggregator

SEPConfig builder class:

Generated SEP

The following SEP is generated by Fluxtion. Note the guard conditions protecting the invocation of the dirtyAggregator_11.publishDirty(). Fluxtion creates a boolean variable for each guard condition. The guard variables are reset in the afterEvent method, which is automatically invoked by the SEP at the end of a processing cycle.

Generated png

The graphical representation of this execution graph as generated by Fluxtion ESC:

Last updated

Was this helpful?