Multi-task data access synchronization
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.
If the same data is accessed by several tasks and the data is written for 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.
| |
Inconsistencies and other risks due to unsecured data access 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. |
General synchronization options between the TcCOM modules are already described in chapter Module-to-module communication. The following mechanisms were described:
- Data exchange via the process image (IO mapping). During this process, the cycle transition, and thus TwinCAT, ensures data synchronicity between the sources and targets.
- Method calls via interfaces in which CriticalSections can be used.
- ADS, which transfers data in the form of a transport medium and thus ensures synchronicity of the data.
- Common data area to be protected by a CriticalSection.
Ideally, however, you should try to avoid the need for synchronization. Otherwise, the simplest way is usually the exchange via the process image, which copies the data between the cycles from the output process images to the input process images and thus ensures a consistent state.
If this is not sufficient and data has to be accessed from different contexts, one of the following options can be used.
It is important to differentiate between the task contexts that are to access the data. In the TwinCAT Runtime, a distinction is made between the Windows kernel mode thread contexts (Windows context for short) and the TwinCAT real-time task contexts (RT context). During initialization of TwinCAT modules, the IP, PS, SP and PI transitions are executed in the Windows context. The SO and OS transitions are executed in the RT context.
The SDK offers appropriate synchronization options for such scenarios. Nevertheless, the TcCOM modules should be designed such that they are independent of each other, at least in the Windows context, and thus do not require synchronization. The transitions in the RT context can use CriticalSections if required.
For the CriticalSection and semaphores it applies that in case of a lock the task waits for the release. In the meantime the core is released for other tasks. With CriticalSections the active task inherits the priority of the waiting task ("Priority Inheritance").