Thread 1 in LabVIEW Program-LabVIEW is an automatic multi-thread language [writing efficient code]

I. LabVIEW is an automatic multithreading Language       Generally, when a VI is run, LabVIEW will run it in at least two threads: one interface thread (ui thread), used to process interface refreshing and user operations on controls; there is also an execution thread responsible for VI in addition to interface operations. LabVIEW is an automatic multi-thread programming language. As long as the VI code can be executed in parallel, LabVIEW will allocate them to multiple execution threads and run them simultaneously.      Figure 1 is a running simple VI, which consists of a separate running loop. In this case, the thread computing burden of this execution loop is particularly heavy, while other threads are basically idle. On a single CPU computer, this thread will occupy almost 100% of the CPU time. The task manager in Figure 1 is intercepted on a dual-core CPU computer. Although this loop can only run on one thread at a time, it does not mean that it is always fixed on one thread. He may run on this thread at this time, and be scheduled to run on another thread at another time. (For this section, read the second chapter of this article: LabVIEW
Will have a deeper understanding of the execution system .)      Therefore,Figure 1 This program can only occupy two CPU cores at most 50% of the total CPU time, each of the two CPU cores is occupied. Figure 1: A dual-core CPU computer executes a heavy computing task        Figure 2 shows the situation when the program has two parallel heavy computing tasks. At this time, LabVIEW will automatically allocate the two tasks to two threads. At this time, even the dual-core CPU will be occupied by 100%.

Figure 2: dual-core CPU computers execute two heavy computing tasks

        From the above example, we can draw the following two conclusions.      1. It is very convenient to Write multi-threaded programs on LabVIEW. We should make full use of this advantage. Generally, you should follow this principle when writing a program: You can place modules that run at the same time side by side. Do not force them to be executed in sequence by means of connections or sequential boxes. During parallel execution, LabVIEW automatically schedules them to run simultaneously in different threads to speed up program execution and save program running time. In the future, multi-core computers will become the mainstream configuration, and the advantages of multithreading will become more obvious.      There are also some special cases. When multithreading is used, the running speed is slow. We will introduce such special cases in detail later.        2. If one or more threads occupy 100% of the CPU, the system will be slow to other threads. For example, if the execution thread of a program occupies 100% of the CPU, the user's operations on the interface will be delayed, and even the user will mistakenly think that the program is deadlocked. Therefore, we should try to avoid 100% CPU usage in the program. At present, most computers are single-core and single-core CPUs, so we should avoid any thread trying to occupy 100% of the CPU (1. The program shown in Figure 2 ).      The simplest solution to this type of problem is to add a latency in the loop. In the examples shown in Figure 1 and 2, if a 100 millisecond delay is added to each cycle, the CPU usage is close to 0.      There is no need to add latency for cycles with a short total running time (if the total CPU usage is less than 100 milliseconds.      In many cases, a loop that runs for a long period of time is usually used only to wait for a task to complete. within such a loop body, there are almost no time-consuming and meaningful operations, therefore, latency must be added in the loop box.        For those operations that really consume CPU resources (such as taking up the CPU for several seconds or even longer), it is best to insert a small amount of latency in the loop, in this way, the CPU should be at least 10% free of time for other threads or processes. Your program will run 10% more time. However, because the CPU can promptly handle the needs of other threads, such as interface operations, other background programs will not be interrupted, but the user will feel that the program seems to run more smoothly. On the contrary, if your program is too domineering, And the CPU is occupied by some operations for a long time, and nothing else can be done, the user cannot be satisfied with such a program.      There is also a case where, for example, some operations may require a program to loop 1,000,000 times, each execution only takes 0.1 milliseconds. At this time, if a latency is inserted in each loop, even if the latency is 1 millisecond, the program speed will be slowed down by 10 times. Of course, this is intolerable. In this case, no latency can be added for each loop, but a 10 ms latency policy can be used after every one thousand cycles. At this point, the program only slows down about 10%, and the CPU has time to process other tasks.        In the VI processing interface operations, the while loop is often used to enclose an event structure. In this case, there is no need to add latency in the loop. When the program runs to event structure, if no event is generated, the program will not continue to execute, but will wait for an event to occur. This is because the thread running this code will temporarily sleep and will not occupy any CPU resources. It will wait until an event occurs before the thread will be awakened again and continue to work.