As we have seen, the user can introduce sleep time to an application by calling the Wait or Wait Until Next ms Multiple functions. Inside a loop, these two VIs can be especially effective. However, great caution must be used when introducing sleep time to VIs running with time-critical priority. The LabVIEW Real-Time Execution System puts the entire thread to sleep; therefore, all VIs on the same time-critical thread go to sleep, even if only one is actually put to sleep during execution. Furthermore, if within a single time-critical VI, there are several parallel loops, all loops will sleep if any one loop is put to sleep. Refer to the illustrations below.
The illustration above shows two different VIs, First.vi and Second.vi, each with a while loop and sleep modes of 200 ms and 20 ms per iteration. If they are both set for time-critical priority in the same execution system, both will sleep for the same amount of time. That is to say even though Second.vi should sleep one-tenth as much as First.vi, it will actually sleep as much as First.vi because all VIs on the time-critical thread are put to sleep if a single time-critical VI sleeps! Therefore, not only will First.vi sleep 200 ms per iteration, but it will also sleep 20 ms every time Second.vi iterates. The same is true for Second.vi. The next illustration below is very similar to the first illustration, except now the two loops are in the same VI. The behavior, however, is the same; when one loop sleeps, the other loop will sleep too if the Two Loops.vi is set for time-critical priority.
The way around this is to put the two loops in separate VIs and give each VI a different time-critical thread by assigning each VI their own execution system (such as standard, instrument I/O, data acquisition, and so on). However, for true determinism, the user should only have one time-critical loop ever running in LabVIEW Real-Time. Also, only time-critical threads running on embedded LabVIEW Real-Time processors experience this global sleeping effect. This is not the case for time-critical threads running on non-LabVIEW Real-Time operating systems, such as Windows, Unix, and so on.
Multithreading in LabVIEW