OpenTestSystem.Otx.Core.Nodes.Node.CompoundNode.Parallel Class Reference

Parallel sequences (threads) More...

Inheritance diagram for OpenTestSystem.Otx.Core.Nodes.Node.CompoundNode.Parallel:

Classes
class	ParallelRealisation
	Represents the parallel realisation More...

Public Attributes
ParallelRealisation	realisation
	Represents the parallel realisation More...
Public Attributes inherited from OpenTestSystem.Otx.Core.Nodes.Node
System.Boolean	disabled
	To turn on/off a node. A deactivated node is not executed at run time. More...
Public Attributes inherited from OpenTestSystem.Otx.Core.UniversalTypes.NamedAndSpecified
ExtensibleData[]	extendedData
	Declares general data for NamedAndSpecified which can be extented by new general data defined in new OTX extensions using the standardised extension mechanism. For example it can be used to specify specification relevant content in a better structured way. More...
OtxId	id
	Unique identifier of an element More...
MetaData	metaData
	Additional tool-specific data More...
OtxName	name
	Name of an element More...
System.String	specification
	Descriptive specification More...

Detailed Description

Parallel sequences (threads)

A parallel node consists of two or more lanes that will be executed simultaneously and synchronously. Nested parallel lanes are supported. Since the Parallel node's normal runtime behaviour is synchronized, a Parallel node will not complete until all of its lanes have completed.

Note

The relative timing of node execution in different lanes is not determined. Race conditions may occur! For that reason one lane should not rely on the execution of any other lane in the Parallel node. In order to gain thread safety, authors should use MutexGroup node.

There are several conditions which induce special completion rules for the Parallel node. The rules will be applied when a Return node, a TerminateLanes node or an Exception occurs in a lane:

• TerminateLanes node
  This special end node induces a special behaviour: If a TerminateLanes node is executed in one of the lanes, all other lanes are signalled to complete prematurely.
  Important: On receiving a premature completion signal, all lanes will complete immediately after completion of the last atomic node, MutexGroup or Finally block (if any). Atomic nodes are Action nodes with an atomic ActionRealisation as well as the end nodes Return, Break, Continue, TerminateLanes and Throw. Since there is no completion timeout defined for atomic nodes, Finally blocks or MutexGroup nodes, lane completion is delayed no matter how long the node takes to complete. This avoids producing undefined states but implies possibilities of deadlocks. An OTX author is responsible for avoiding deadlock situations.
  Important: Terminating a called Procedure using TerminateLanes is not recommended because the behaviour may not be predictable. It is possible that the author of the called Procedure did not expect it to be terminated from the outside at arbitrary positions. Thus, it is recommended practice to pass a flag into the called Procedure, so that the called Procedure can terminate itself in a controlled manner.
• Return node
  If a Return node is executed in one of the lanes, the lane will complete, but the jump induced by the Return node will be delayed until all other lanes complete. After this, the Procedure completes.
• Throw of an unhandled exception
  If a node in one of the lanes throws an exception which is not handled in that lane, the lane will complete, but the Throw is delayed until all other lanes have completed. After this, the exception is thrown upwards. If more than one exception was delayed, the first thrown exception shall be thrown upwards and the others will be discarded.
  Important: When there are two or more delayed exceptions which occurred simultaneously (same timestamp), it is not specified which exception will be thrown upwards.
  Important: When there is a delayed exception and a delayed Return which occurred simultaneously (same timestamp), the behaviour is unspecified. It depends on the specific runtime implementation whether an exception is thrown upwards or the Procedure completes.

Syntax

parallel
{
    lane
    {
        ...
    }
    lane
    {
        ...
    }
    ...
}

Example

// Local Declarations
Integer funds = 200;
// Flow
parallel
{
    lane
    {
        funds = 0;
    }
    lane
    {
        mutex
        {
            if ((funds > 100))
            {
                Hmi.ConfirmDialog("Spend money", null, @MessageTypes:INFO, null);
            }
            else
            {
            }
        }
    }
}

Checker rules

Core.CheckerRule.Core_Chk015 - Correct nesting of Parallel nodes

See also

Nodes.Node.CompoundNode.MutexGroup, Nodes.Node.EndNode.TerminateLanes, Nodes.Node.EndNode.Return, Nodes.Node.EndNode.Throw

Member Data Documentation

realisation

ParallelRealisation OpenTestSystem.Otx.Core.Nodes.Node.CompoundNode.Parallel.realisation

Represents the parallel realisation