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

Thread-Synchronisation More...

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

Public Attributes
Flow	realisation
	A Flow of nodes which will be executed one by one in the order of appearance. 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

Thread-Synchronisation

The MutexGroup node is designed for resolving concurrency issues which might occur within the scope of Parallel nodes. Syntactically, the MutexGroup node has similarities to the Group node because it can be used to wrap a sequence of nodes together, but beyond that it has special semantics concerning parallel execution.

In multi-threaded environments, more than one process may try to access the same variable(s). This can cause serious concurrency issues and has to be dealt with properly. In general, parts of code where multiple threads try to access the same variable(s) are called critical sections. By only allowing one thread at a time to enter a critical section, access is effectively reduced to one thread at a time – other threads have to wait for their turn. The OTX MutexGroup node allows wrapping critical sections so that access happens in a controlled manner (as it is mutually exclusive). Since only one MutexGroup will be executed at a time, variable access in the critical sections becomes thread safe. Entry to the critical section will be controlled by one internal, global object.

Note

Please keep in mind that a MutexGroup has strong influence on the execution performance and only use it, if it is really necessarry.

Syntax

mutex
{
    ...
}

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
            {
            }
        }
    }
}

Member Data Documentation

realisation

Flow OpenTestSystem.Otx.Core.Nodes.Node.CompoundNode.MutexGroup.realisation

A Flow of nodes which will be executed one by one in the order of appearance.