Thread 4 in LabVIEW Program-thread for dynamically connecting database functions [writing efficient code]

Thread 4 in LabVIEW Program-thread of dynamically connected library function 4. Thread of dynamically connected Library Function 1. Thread settings in CLN

   LabVIEW can use the CLN (call library function node) node to remove the functions in the dynamic connection library. In Windows, it refers to the functions in the. dll file. You can use the configuration Panel of the CLN node to specify the thread where the called function runs. Compared with the VI thread configuration, the CLN thread options are very simple. There are only two options: interface thread (run in Ui thread) and reentrant ).

 
Figure 1: select the function running thread on the CLN configuration panel

  In the LabVIEW program diagram, we can directly see which thread is selected for a CLN node. If it is in the interface thread, the node color is darker orange; if it is reentrant, the self-node is lighter yellow.

 
Figure 2: different colors indicate different CLN thread settings

2. How to Select a proper thread

   There is a simple method to determine which thread is selected in CLN. If the dynamic connection library you want to use is safe with multiple threads, you can choose the reentrant mode. Otherwise, the dynamic connection library is not safe with multiple threads, select the interface thread mode.
   It is also troublesome to determine whether a dynamic Connection Library is thread-safe. If the dynamic connection library document does not explicitly indicate that it is safe with multiple threads, it should be non-linear and secure. If you can see the source code of the dynamic connection library, there are global variables, static variables in the Code, or no locks in the code.
For one type of operations, this dynamic Connection Library is certainly not safe with multiple threads.

   With the reentrant method selected, LabVIEW runs the dynamic Connection Library Function in the most convenient thread, and generally runs in the same thread as the vi that calls it. Because LabVIEW is an automatic multi-threaded language, it is also likely to allocate the dynamic connection library function to a separate thread for running. If there are two CLN nodes in the program that do not have a direct or indirect relationship, LabVIEW is likely to run the functions they call in different threads at the same time, maybe the same function. This operation is dangerous for non-multithreading secure dynamic connection libraries. It can easily cause data confusion or even program crashes.

   Select the interface thread mode: Because LabVIEW only has one interface thread, if all CLN settings are interface threads, you can ensure that all the functions called by CLN are running under the same thread, it will certainly not be called at the same time. For non-multithreading secure dynamic connection libraries, this ensures its security.

3. Works with the thread options of vi

   If a large number of dynamic connection library functions are frequently called in your program, efficiency is a very noteworthy issue.

   I have compiled a program used in LabVIEW.
OpenGL demo program (to demonstrate the "Import shared library function" we developed), all OpenGL calls are completed in CLN mode. Since all OpenGL operations must be completed in the same thread, I set all clns to run in the interface thread. The thread options of VI are not modified or the default options. As a result, the program runs very slowly. Only one frame of image can be refreshed every second, And the CPU usage is 100%. However, at least 25 frames per second can be smoothly watched as an animation.
   I started to try to use the profile tool of LabVIEW to find the inefficient VI, and the results could not be found. The CPU usage shown on the profile performance and Memory tool is only a little bit. This tool does not display the most time-consuming operations in the program. Naturally, I have no idea how to optimize the program. Later, the demo program was put on hold for a while.

   It was not until one day that I was inspired by some information my colleagues gave me that I suddenly figured out that all these CPUs were consumed in thread switching. We call the OpenGL method to wrap an api vi for each OpenGL API function. These api vi are very simple, and the program diagram has only one CLN node and calls the corresponding OpenGL function. Since each VI runs in the default execution thread, CLNThe called function runs under the interface thread. Therefore, this API is executed once each time.
VI and LabVIEW both need to perform two thread switches, switch from the execution thread to the interface thread, execute the function, and switch back to the execution thread.
   Thread switching is time-consuming. My demo calls OpenGL api vi about two thousand times to refresh a frame, which takes nearly one second.

   To solve this problem, either change CLN in all api vi to the reentrant mode, but it is difficult to ensure that all called functions run in the same thread during programming. It is easy to implement that all the Vi related to OpenGL operations in the program are set to run under the interface thread. The last method is selected. In the improved program, 30 images per second will not occupy the CPU.

   As a result, I also figured out another problem. That is, I once found that
The error message is lost in Windows API functions. When the return value of a Windows API function is 0, an error occurs. In this case, you can call getlasterr and formatmessage to get the error code and information. However, I often encounter the following problem: the previous function clearly returned a value of 0, but the getlasterr function called subsequently cannot find the error code.
   I think it must be that two functions are called by LabVIEW successively, but in fact LabVIEW needs to perform two thread switches between them. The error code is lost during thread switching. The solution to this problem is to set CLN for calling the three functions and VI for calling them to run in the interface thread.