...
Parallelization Mechanism Introduction
Parallel processing in FPM is initiated by the process itself from its main thread by spawning child threads and once the child threads are running, main thread is monitoring their status and waiting till all child threads finish. Once finished, the main thread continues. It’s important to note that all parallel enabled processes in FPM share common code for both the main thread and child threads. This means that both are implemented by a single TI process.
...
Parallelization Mechanism Details
Main Thread Role
Main thread serves two purposes. It spawns child threads and once spawned it starts to monitor the child threads and wait until all child threads have finished.
Monitoring of the threads runs in two phases, first during the initiation of the child threads and second during their execution. The main thread watches for timeouts during both phases to prevent zombie threads running on the server.
The main thread has the option to participate in data processing. However, doing so might compromise its capability to identify time out scenarios. This is because the main thread itself could time out, preventing it from accessing the code that oversees the child threads.
Spawning Threads
Data Allocation to Threads
no mapping between source and target cube dimensions
mapping between source and target cube dimensions
Thread Polling Mechanism
As of TM1 version 11 there are no dedicated thread synchronization aren’t any specific functions for synchronizing threads in parallel processes and thus . The current solution relies depends on polling checking the thread status in the }APQ C3 Thread Control cube. The polling is always provided by the main thread, child threads are only responsible to signal their status into main process always performs this check, while the child threads only need to update their status in the }APQ C3 Thread Control cube.
The polling checking mechanism relies is based on issuing the periodic execution of the CubeSaveData command on the }APQ C3 Thread Control cube and is run by the . The main process in runs this command at short intervals to enable the main process to see any data , allowing it to detect any changes in the }APQ C3 Thread Control cube data from the child threads. This makes sure the main thread can detect data changes in the control cube during the child threads execution as TM1 commit model will normally not allow to see the data changes in the cube from any other process until the process modifying data exits. This approach has its downsides, but it doesn’t rely on any is crucial because TM1's 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 purely entirely as TI code. It is important to understand that all parallel enabled processes in FPM have common code for the logic of both main process and child threads, so only one TI process implements both.
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.
Parallelization Mechanism Details
Main Thread Role
only monitor threads
involve in data processing - timeout miss risk
Spawning Threads
Data Allocation to Threads
...
no mapping between source and target cube dimensions
...
Thread Initiation Polling
...