A centralized LabVIEW processing method for specifying software and hardware resources

Abstract

The invention discloses a centralized LabVIEW processing method for specifying software and hardware resources. The structure of resource operation vi is composed of a while loop plus a conditional structure. The stop condition of the while loop is set to always be true. Each time the vi is called, it only loops once. The enumeration control operation item includes all operations on the resource, and each operation corresponds to each other through the conditional structure branch. The resource handle generated after opening the resource is recorded in the memory through the shift register of the while loop. The resource is always in the open state and recorded in the shift register. Other operations obtain the resource handle from the shift register for execution. The invention achieves centralized processing of resource operations, and one vi completes all operations on the resource. The invention sets the attribute of the resource operation vi to non-reentrant execution, and when multiple threads operate on a single resource, resource conflicts will not be caused. The invention facilitates independent thread operations on resources by adding a queue without affecting the main thread.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to a centralized LabVIEW processing method for specifying software and hardware resources. Background Art

[0002] In the normal process of writing project applications, it is often necessary to read and write external software and hardware resources, such as the database interface on the computer or the instruments connected to the computer RS232 serial port. These resources are unique in the entire system, which means that in any period of time, there can only be one program thread calling this resource. If one thread has already called this resource and another thread calls it, the program will have unpredictable errors, or the second thread will not be able to call the thread directly, causing conflicts.

[0003] At present, the general practice is to write the entire application in single-threaded mode as much as possible, at least the operation of a certain resource is only in one main thread, so that the call to a certain resource during the program is unique, which fundamentally eliminates the call conflict problem between different threads. This is feasible in many cases, but this approach will lead to the resource call speed, and the resource execution time will be accumulated on the main thread of the program. For example, when saving test data to the database, the main thread must wait until the save is completed before executing the next operation. Once the save speed is slow, it will slow down the rhythm of the entire main thread. Another premise is that a certain resource must be operated in a single thread. If multi-threading is required, it will not work. You can only add a global Boolean value to mark whether the resource is in use, which is not so flexible. In addition, each time the resource is operated, it must be closed and opened by another thread, which invisibly increases the running time. Summary of the invention

[0004] The purpose of the present invention is to provide a centralized LabVIEW processing method for specifying software and hardware resources, so as to realize easy resource calling in multiple threads and avoid resource conflicts. In addition, when the main thread does not need to know the resource calling result, the execution of the resource does not affect the execution efficiency of the main thread.

[0005] The technical solution of the present invention is:

[0006] A centralized LabVIEW processing method for specifying software and hardware resources. The structure of the resource operation vi is composed of a while loop plus a conditional structure. The while loop stop condition is set to always be true. Each time this vi is called, it only loops once.

[0007] The enumeration control operation items include all operations on resources, and each operation corresponds to each other through conditional structure branches; the resource handle generated after opening the resource is recorded in the memory through the shift register of the while loop. The resource is always in the open state and recorded in the shift register. Other operations obtain the resource handle from the shift register for execution.

[0008] Preferably, in order to prevent resource operation vi from causing resource operation conflicts when running in different threads, the property of the resource operation vi is set to non-reentrant execution; non-reentrant execution means that there is only one copy of this vi in ​​the memory, and each time the thread needs to call the resource operation vi, this copy is run. If vi has been called for execution, the system automatically suspends other callers until the current operation is completed, and the system lets vi execute the next operation in sequence.

[0009] Preferably, if there is a situation where the next step can be performed without waiting for the resource operation to be completed, then a queue needs to be added: the queue, as a message consumer, is a separate child thread; when the main thread generates a queue message, the queue consumer vi executes the specified operation, and the main thread immediately proceeds to the next step after sending the queue message.

[0010] The advantages of the present invention are:

[0011] 1. The centralized LabVIEW processing method for specifying software and hardware resources proposed in the present invention achieves centralized processing of resource operations, and one VI completes all resource operations.

[0012] 2. The present invention sets the attribute of the resource operation vi to non-reentrant execution, so that when multiple threads operate on a single resource, resource conflicts will not occur.

[0013] 3. The present invention adds a queue to facilitate independent thread operations on resources when necessary without affecting the main thread. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The present invention will be further described below in conjunction with the accompanying drawings and embodiments:

[0015] Figure 1 Provides a structural framework for resource operations vi;

[0016] Figure 2 Provides a structural framework for queue consumers. DETAILED DESCRIPTION

[0017] like Figure 1The following is a structural framework of a simple resource operation vi. The overall structure is based on functional global variables and is also composed of a while loop plus a conditional structure. The while loop stop condition is set to always true, which means that each time this vi is called, it only loops once. The enumeration control operation item contains all operations on resources, and each operation corresponds to each other through the conditional structure branch. The resource reference or resource handle generated after opening the resource is recorded in the memory through the shift register of the while loop. The advantage of this is that the resource is always in the open state and recorded in the shift register. Other operations only need to obtain the resource handle from the shift register to execute, without repeatedly opening and closing the resource.

[0018] In order to prevent resource operation vi from causing resource operation conflicts when running in different threads, the vi attribute is set to non-reentrant execution. Non-reentrant execution means that there is only one copy of this vi in ​​the memory. Whenever a thread needs to call the resource operation vi, this copy is run. If vi has been called for execution, the system automatically suspends other callers until the current operation is completed. The system then lets vi execute the next operation in sequence. In this way, through the system's own interlocking, resource conflicts are avoided, the complexity of programming is simplified, and some unnecessary errors are avoided.

[0019] If the resource operation vi is integrated into the thread process, the time consumed by the resource operation will still be accumulated in the thread execution. Of course, if the thread itself needs to wait for the resource operation to complete before proceeding to the next step, then such time accumulation is necessary and allowed. However, if there are some situations where the next step can be proceeded without waiting for the resource operation to complete, then a queue needs to be added, such as Figure 2 As shown in the figure, the queue is a message consumer and a separate child thread. When the main thread generates a queue message, the queue consumer vi can perform the specified operation, and the main thread can immediately perform the next operation after sending the queue message. In this way, the operation of resources can be independent of the main thread and will not affect the main thread.

[0020] The above embodiments are only for illustrating the technical concept and features of the present invention, and their purpose is to enable people familiar with the technology to understand the content of the present invention and implement it accordingly, and they cannot be used to limit the protection scope of the present invention. Any modifications made according to the spirit of the main technical solution of the present invention should be included in the protection scope of the present invention.

Claims

1. A centralized LabVIEW processing method for specifying software and hardware resources, characterized in that: The structure of resource operation vi is composed of while loop plus a conditional structure. The stop condition of while loop is set to always true. Each time this vi is called, it loops only once. The enumeration control operation items include all operations on resources, and each operation corresponds to each other through the conditional structure branch. The resource handle generated after opening the resource is recorded in the memory through the shift register of the while loop. The resource is always in the open state and recorded in the shift register. Other operations obtain the resource handle from the shift register for execution. In order to prevent resource operation conflicts when the resource operation vi is running in different threads, the attribute of the resource operation vi is set to non-reentrant execution; Non-reentrant execution means that there is only one copy of this vi in ​​the memory. Whenever a thread needs to call a resource operation vi, this copy is run. If vi has been called for execution, the system automatically suspends other callers until the current operation is completed. The system then lets vi execute the next operation in sequence. If there is a situation where you can proceed to the next step without waiting for the resource operation to be completed, then you need to add a queue: the queue, as a message consumer, is a separate child thread; when the main thread generates a queue message, the queue consumer vi performs the specified operation, and the main thread immediately proceeds to the next step after sending the queue message.

Images