As of TM1 version 11 there aren’t any specific functions for synchronizing threads in parallel processes. The current solution depends on periodic checking the thread status in the }APQ C3 Thread Control cube. The main process always performs this check, while the child threads only need to update their status in the }APQ C3 Thread Control cube.
The checking mechanism is based on the periodic execution of the CubeSaveData command on the }APQ C3 Thread Control cube and checking thread status in the }APQ C3 Thread Control cube. The main process runs this command at short intervals, allowing it to detect any changes in the data from the child threads. This is crucial because TM1 commit model typically doesn't allow other processes to see data changes in a cube until the process that's modifying the data has finished.
This method ensures that the main thread can identify changes in the control cube while the child threads are running. Although this approach has its drawbacks, it doesn’t depend on semaphore files or external software and is implemented entirely as TI code.
The polling interval can be configured in }APQ Settings cube, default value is 5 seconds. Setting the value too low might result in locking issues, setting the value too high will cause the main thread to wait unproductively. In worst case the main thread would wait for the entire polling period despite all threads have already finished.
Note: The situation will change with TM1 version 12, which will no longer support CubeSaveData command, but will support thread synchronization out of the box. As a possible solution to this problem, there could be two versions of the parallel enabled processes in the FPM model - one for version 11 and second for version 12 and above. Switching between these can be simply provided by modified roundtrip configurations or by assigning proper process version to respective roundtrip step.