Multi-task data access synchronization in the PLC

When one set of data is accessed by multiple tasks, the tasks may access the same data simultaneously, depending on the task/real-time configuration. If the data is written by at least one of the tasks, the data may have an inconsistent state during or after a change. To prevent this, all concurrent accesses must be synchronized so that only one task can access the shared data at a time.

These concurrent accesses from several tasks that require synchronization include the following cases, for example:

Direct access to global or other non-temporary variables, for example using operators
Indirect access to global or other non-temporary variables, for example within functions, methods, or other POU calls (especially if a function block instance is globally instantiated)

In brief: If one set of data is accessed by several tasks and the data is written by at least one of these accesses, all read and write accesses must be synchronized. This applies regardless of whether the tasks are run on a single or multiple CPU cores.

WARNING

Risk of injury due to unforeseen axis movement

If concurrent accesses are not synchronized, there is a risk that the data records will be inconsistent or invalid. Depending on how the data is used in the further course of the program, this can result in incorrect program behavior, undesired axis movement, or even a sudden program standstill. Damage to equipment and workpieces may occur, or people's health and lives may be endangered, depending on the controlled system.

Synchronize concurrent accesses.
You will find function tests with corresponding explanations in the sample programs for the MUTEX procedures, which demonstrate why it is necessary to synchronize accesses.

Synchronization options

The following options are available for synchronizing accesses:

1) Mutex procedure (TestAndSet, FB_IecCriticalSection) for securing critical sections

The number of critical sections must always be kept as small as possible.
The critical sections must be kept short.
Use FB_IecCriticalSection for comparatively short critical sections.
Use TestAndSet for comparatively long critical sections.

2) Data exchange via the PLC process image

This variant is only possible and recommended if only one task has write access to the same data.
The possible data volume is limited due to necessary internal copy actions.

For further information, please refer to the description Data exchange via the PLC process image.

3) Data exchange via synchronized buffers

This variant is only possible if only one task has write access to the same data.
This is a user-specific implementation for which there are various options.
Access to the individual buffers must be secured, for example with TestAndSet().
The possible data volume is limited due to executed copy actions.

For further information, please refer to the description Data exchange via synchronized buffers.

Synchronization also in the case of atomic access

The necessity for synchronization normally also applies even if a single access to a variable (e.g. writing an integer) could be described as atomic, i.e. uninterruptible.

Because the property of the atomic access depends among other things on the processor architecture used, every access should be regarded as non-atomic for simplicity's sake and in particular for safety.

Note that even supposedly safe accesses almost always turn out to be unsafe when considered more closely. This is explained below with the help of two example scenarios:

As a rule, more than one atomic access is necessary for the desired function expression (e.g. read, change, write). If such a multi-part function expression exists in several tasks, the simultaneous execution on several tasks can lead to a different result than the sequential execution of the expressions.

Example: A global counter variable (initialized with 0) is to be incremented by 1 (from two tasks) (nGlobal := nGlobal + 1;). If the increment is performed simultaneously, the calculation 0 + 1 = 1 is performed both times, and the resulting value of the global variable is 1, even though the expected and intended value would be 2.

Several read accesses at different times within a task execution can deliver different variable values.

Example: A global variable is written from a task. Its value was previously 50 (nGlobal := 50;) and is now written to 0 (nGlobal := 0;). In a different task context the value of the global variable is queried (IF nGlobal>10 AND nGlobal<20 THEN). The query consists of two read accesses. If the above write access takes place from the other task between these read accesses, then the condition is fulfilled, even though the global variable did not have a value of between 10 and 20 at any point in time!

Further information

System operators such as ADD, SIZEOF or __NEW can be called by several tasks simultaneously. This statement only refers to the operator used. If data is accessed during the calls, which in turn is used by several tasks, these data accesses must be synchronized accordingly.
A function block instance that uses ADS internally must not be used in different tasks. If the instance is nevertheless called from another task, the error ADSERR_DEVICE_INVALIDCONTEXT=0x709=1801 is issued.
Due to the execution on the stack, the use of the STRING functions (Tc2_Default library) in different tasks is not critical in TwinCAT 3 (in TwinCAT 2 the STRING functions are not secure by default for task changes).
Also note the possibilities of the Static Analysis compiler extension, which provides rules on the topic of “concurrency/competing accesses”. This should be seen as a tool that can be used to detect potential synchronization requirements (see TE1200 TwinCAT 3 PLC Static Analysis documentation, rules SA0006 and SA0103).

Further Information