A multi-thread synchronization vehicle end data acquisition method and device

Abstract

The application relates to a multi-thread synchronization vehicle terminal data acquisition method and device, which comprises the following steps: associating operation commands of a vehicle terminal data acquisition tool with corresponding execution function interfaces; constructing a command queue and inserting the operation commands into the command queue; starting a command execution thread, polling and checking the command queue, and sequentially executing the execution function interfaces associated with the operation commands in the command queue if the command queue is not empty; and judging whether the next operation command in the command queue needs the return result of the current operation command, and blocking and waiting for the command execution thread if the next operation command needs the return result of the current operation command. The application serializes the conventional user operation which needs to sequentially access each module thread, simplifies the code and reduces program errors.

Description

Technical Field

[0001] This invention relates to the field of data acquisition technology, specifically to a multi-threaded synchronous vehicle-side data acquisition method and apparatus. Background Technology

[0002] A crucial step in acquiring the large amount of data needed for map navigation is the collection, labeling, and transmission of data from onboard sensors by vehicle-mounted data acquisition tools. As an intermediary in data collection, these tools need to exchange data with hardware data generation software, synchronize information collection with cloud servers, and simultaneously store data in a local database. To integrate these relatively independent yet data-related functions, Qt is typically chosen as the software interface framework. For richer interface effects, the front-end can be written in QML, with each module running on different threads to ensure parallelism. Qt's flexible signal / slot mechanism can handle data transfer and operation execution. However, as the number of threads increases, the need for logical jumps between threads with return values ​​makes coding complex.

[0003] Qt's signal / slot mechanism uses a queue connection method to allow connected signals and slots to be sent and executed on different threads. Signals can carry parameters, but the return value of slot execution cannot be obtained without establishing a new signal / slot connection. If a user operation on the interface combines steps such as accessing sensor data, operating the local database, and calling a cloud HTTP interface, adding a pair of execution / return signals / slots between the threads of each module will result in a huge amount of coding, complex data transmission paths, and a high risk of errors. Summary of the Invention

[0004] This invention addresses the technical problems existing in the prior art by providing a multi-threaded synchronous vehicle-side data acquisition method and device, which serializes the conventional user operations that require sequential access to various module threads, simplifying the code and reducing program errors.

[0005] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: In a first aspect, the present invention provides a multi-threaded synchronous vehicle-side data acquisition method, comprising: The operation commands and corresponding execution function interfaces of the associated vehicle-side data acquisition tool; Construct a command queue and insert operation commands into the command queue; Start the command execution thread, poll and check the command queue. If the command queue is not empty, execute the execution function interface associated with each operation command in the command queue in turn. Determine whether the next operation command in the command queue requires the return result of the current operation command. If so, block the command execution thread and wait.

[0006] Furthermore, inserting the operation command into the command queue includes: based on the operation command trigger signal of the vehicle-side data acquisition tool, using a signal / slot mechanism, inserting the operation command into the command queue by the slot corresponding to the signal.

[0007] Furthermore, the aforementioned blocking and waiting of the command execution thread is achieved through Qt's event loop mechanism.

[0008] Secondly, the present invention provides a multi-threaded synchronous vehicle-side data acquisition device, comprising: The associated module contains the operation commands and corresponding execution function interfaces of the vehicle-side data acquisition tool. The queue construction module constructs a command queue and inserts operation commands into the command queue. The command execution module starts the command execution thread, polls and checks the command queue, and if the command queue is not empty, it executes the execution function interface associated with each operation command in the command queue in turn. The waiting and judgment module determines whether the next operation command in the command queue requires the return result of the current operation command. If so, it causes the command execution thread to block and wait.

[0009] Thirdly, the present invention provides an electronic device, comprising: Memory, used to store computer software programs; A processor is used to read and execute the computer software program, thereby implementing the multi-threaded synchronous vehicle-side data acquisition method described in the first aspect of the present invention.

[0010] Fourthly, the present invention provides a non-transitory computer-readable storage medium storing a computer software program for implementing a multi-threaded synchronous vehicle-side data acquisition method as described in the first aspect of the present invention.

[0011] The beneficial effects of this invention are: it combines the flexibility of Qt signals / slots with the parallelism of multithreading. It simplifies the writing of logic code, reduces the amount of code, and avoids the problem of synchronization issues between threads. Attached Figure Description

[0012] Figure 1 A flowchart of a multi-threaded synchronous vehicle-side data acquisition method provided in an embodiment of the present invention; Figure 2 This is a structural diagram of a multi-threaded synchronous vehicle-side data acquisition device provided in an embodiment of the present invention; Figure 3 A schematic diagram of an embodiment of the electronic device provided in this invention; Figure 4This is a schematic diagram of an embodiment of a computer-readable storage medium provided in this invention. Detailed Implementation

[0013] The principles and features of the present invention are described below with reference to the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0014] In this embodiment of the invention, the vehicle-side data acquisition tool, while running tasks for various modules in a multi-threaded manner (including receiving various types of sensor data using a sensor data receiving thread, implementing data CRUD functions using a local database operation thread, and calling cloud interfaces to obtain and upload data using a cloud interface call thread), constructs a new thread to execute the logic for user operations. A queue is used to store commands sent from the front end, and the execution thread polls the queue to execute the corresponding command logic. When data needs to be transferred between threads, Qt's event loop mechanism is used to wait for a signal, blocking the current thread until the result is returned before continuing execution, thereby achieving synchronization of operations across threads.

[0015] Specifically, embodiments of the present invention provide a multi-threaded synchronous vehicle-side data acquisition method, such as... Figure 1 As shown, it includes the following steps: S100 associates the operation commands of the vehicle-side data acquisition tool with the corresponding execution function interface, thereby establishing a connection (map) between the types of signals (enum) sent by the front end and the corresponding execution interface (member function pointer).

[0016] S200, construct a command queue and insert operation commands into the command queue. Based on the operation command trigger signal from the vehicle-side data acquisition tool, the operation command is inserted into the command queue using the signal / slot mechanism corresponding to the signal.

[0017] S300: Start the command execution thread, poll and check the command queue. If the command queue is not empty, execute the execution function interface associated with each operation command in the command queue in sequence. After execution, delete the operation command from the command queue.

[0018] S400 determines whether the next operation command in the command queue requires the return result of the current operation command. If so, it causes the command execution thread to block and wait.

[0019] In addition to the main interface thread, the vehicle-side data acquisition tool also runs separate threads for receiving sensor data, operating a local database, and calling cloud APIs. The sensor data receiving thread receives data from various sensors, the local database operation thread performs CRUD (Create, Read, Update, Delete) functions on the data, and the cloud API calling thread calls cloud APIs to acquire and upload data.

[0020] User actions and commands are characterized by their unpredictability and timeliness (interface operations generally require that non-demand actions do not cause blocking). However, background resource and device usage, as well as certain logical sequences, require blocking or prioritization. Using a command queue can better balance these two requirements.

[0021] The execution logic of a single command is generally sequential. Existing technologies, when using signal / slot mechanisms between threads, sample the QueuedConnection connection for the signal / slot and do not block after sending. This results in frequent jumps between threads using the signal / slot mechanism, making the process appear cluttered, difficult to implement, and detrimental to later code maintenance. Each time a thread calls a result, an additional pair of signals / slots must be added, significantly increasing the implementation burden. Furthermore, without using a serial queue to synchronize command execution, instruction signal 1 from the front end might arrive before its corresponding processing steps are completed, and instruction signal 2 might arrive. If the processing of instruction signal 1 is blocked, then the processing steps for instruction signal 2 must begin execution. Theoretically, instruction signal calls have a sequential logical relationship, leading to logical confusion and problems. In this invention, the blocking and waiting for signal returns is implemented using Qt's event loop mechanism. This synchronization operation simplifies and clarifies the command execution logic.

[0022] Figure 2 This is a structural diagram of a multi-threaded synchronous vehicle-side data acquisition device provided in an embodiment of the present invention. Figure 2 As shown, the device includes: The associated module contains the operation commands and corresponding execution function interfaces of the vehicle-side data acquisition tool. The queue construction module constructs a command queue and inserts operation commands into the command queue. The command execution module starts the command execution thread, polls and checks the command queue, and if the command queue is not empty, it executes the execution function interface associated with each operation command in the command queue in turn. The waiting and judgment module determines whether the next operation command in the command queue requires the return result of the current operation command. If so, it causes the command execution thread to block and wait.

[0023] Please see Figure 3 , Figure 3 This is a schematic diagram illustrating an embodiment of the electronic device provided in this invention. For example... Figure 3 As shown, this embodiment of the invention provides an electronic device 500, including a memory 510, a processor 520, and a computer program 511 stored in the memory 510 and executable on the processor 520. When the processor 520 executes the computer program 511, it performs the following steps: The operation commands and corresponding execution function interfaces of the associated vehicle-side data acquisition tool; Construct a command queue and insert operation commands into the command queue; Start the command execution thread, poll and check the command queue. If the command queue is not empty, execute the execution function interface associated with each operation command in the command queue in turn. Determine whether the next operation command in the command queue requires the return result of the current operation command. If so, block the command execution thread and wait.

[0024] Please see Figure 4 , Figure 4 This is a schematic diagram illustrating an embodiment of a computer-readable storage medium provided by an embodiment of the present invention. For example... Figure 4 As shown, this embodiment provides a computer-readable storage medium 600, on which a computer program 611 is stored. When the computer program 611 is executed by a processor, it performs the following steps: The operation commands and corresponding execution function interfaces of the associated vehicle-side data acquisition tool; Construct a command queue and insert operation commands into the command queue; Start the command execution thread, poll and check the command queue. If the command queue is not empty, execute the execution function interface associated with each operation command in the command queue in turn. Determine whether the next operation command in the command queue requires the return result of the current operation command. If so, block the command execution thread and wait.

[0025] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0026] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0027] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0028] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0029] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0030] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0031] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A multi-threaded synchronous vehicle-side data acquisition method, characterized in that, include: The operation commands and corresponding execution function interfaces of the associated vehicle-side data acquisition tool; Construct a command queue and insert operation commands into the command queue; Start the command execution thread, poll and check the command queue. If the command queue is not empty, execute the execution function interface associated with each operation command in the command queue in turn. Determine whether the next operation command in the command queue requires the return result of the current operation command. If so, block the command execution thread and wait. When data needs to be transferred between threads, Qt's event loop mechanism is used to wait for a signal to block the current thread, and then continue execution after the result is returned, thereby achieving synchronization of operations between threads.

2. The method according to claim 1, characterized in that, The insertion of the operation command into the command queue includes: based on the operation command trigger signal of the vehicle-side data acquisition tool, using a signal / slot mechanism, inserting the operation command into the command queue by the slot corresponding to the signal.

3. The method according to claim 1, characterized in that, The aforementioned blocking and waiting of the command execution thread is achieved through Qt's event loop mechanism.

4. A multi-threaded synchronous vehicle-side data acquisition device, characterized in that, include: The associated module contains the operation commands and corresponding execution function interfaces of the vehicle-side data acquisition tool. The queue construction module constructs a command queue and inserts operation commands into the command queue. The command execution module starts the command execution thread, polls and checks the command queue, and if the command queue is not empty, it executes the execution function interface associated with each operation command in the command queue in turn. The waiting and judgment module determines whether the next operation command in the command queue needs the return result of the current operation command. If so, it causes the command execution thread to block and wait. When data needs to be transferred between threads, Qt's event loop mechanism is used to wait for a signal to block the current thread, and then continue execution after the result is returned, thereby achieving synchronization of operations between threads.

5. The apparatus according to claim 4, characterized in that, The queue construction module is specifically used to: based on the operation command trigger signal of the vehicle-side data acquisition tool, and using the signal / slot mechanism, insert the operation command into the command queue by the slot corresponding to the signal.

6. The apparatus according to claim 4, characterized in that, The aforementioned blocking and waiting of the command execution thread is achieved through Qt's event loop mechanism.

7. An electronic device, characterized in that, include: Memory, used to store computer software programs; A processor is used to read and execute the computer software program, thereby implementing the multi-threaded synchronous vehicle-side data acquisition method according to any one of claims 1-3.

8. A non-transitory computer-readable storage medium, characterized in that, The storage medium stores a computer software program for implementing a multi-threaded synchronous vehicle-side data acquisition method as described in any one of claims 1-3.

Images