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

Thread-Synchronisation More...

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

Public Attributes

MutexFlow realisation
 A MutexFlow 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...
 
NamedAndSpecifiedSpecification[] 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;
MutexLock mutexLock1;
// Flow
parallel
{
lane
{
funds = 200;
}
lane
{
mutex
{
if (funds > 100)
{
HMI.ConfirmDialog("Spend money", NULL, @MessageType:INFO);
}
else
{
}
}
}
lane
{
mutex(mutexLock1)
{
if (funds > 100)
{
HMI.ConfirmDialog("Using mutexLock 1", NULL, @MessageType:INFO);
}
else
{
}
}
}
lane
{
mutex(mutexLock1)
{
if (funds > 100)
{
HMI.ConfirmDialog("Using mutexLock 2", NULL, @MessageType:INFO);
}
else
{
}
}
}
}

Member Data Documentation

◆ realisation

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

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