Multi-core communication method and device based on hardware-assisted semaphore, equipment and medium

Abstract

The application discloses a multi-core communication method and device based on hardware-assisted semaphores, equipment and medium, and relates to the technical field of computers. The method comprises the following steps: determining a target hardware-assisted semaphore from a preset semaphore state bitmap based on queue request information; creating a target remote procedure call communication queue, and determining queue metadata related to the target hardware-assisted semaphore and the target remote procedure call communication queue; registering the queue metadata to a lock-free hash table based on an atomic operation, so as to establish a binding relationship between the target hardware-assisted semaphore and the target remote procedure call communication queue; and based on the binding relationship, completing multi-core communication of different subsystems through the target remote procedure call communication queue and the target hardware-assisted semaphore. It can be seen that the application can avoid the problem of asynchronous allocation and creation of semaphores and queues, avoid waste caused by long-term idling of resources, effectively improve the communication running efficiency in a multi-core environment, and guarantee the real-time response capability of the system.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a multi-core communication method, apparatus, device, and medium based on hardware-assisted semaphores. Background Technology

[0002] Traditional multi-core processor inter-core communication systems have significant problems in resource management: First, hardware auxiliary semaphores and communication queues are managed separately, which can easily lead to asynchronous allocation and creation of the two; second, a large number of hardware auxiliary semaphores are idle for a long time, resulting in a waste of hardware resources; third, the use of locking mechanisms to implement data transmission and reception of remote procedure call (RPC) queues will significantly reduce operating efficiency in a multi-core environment and seriously affect the real-time response capability of the inter-core communication system. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a multi-core communication method, apparatus, device, and medium based on hardware-assisted semaphores, which can avoid the problems of asynchronous allocation and creation of semaphores and queues; avoid the waste caused by long-term resource idleness; effectively improve the communication efficiency in a multi-core environment; and ensure the real-time response capability of the system. The specific solution is as follows:

[0004] In a first aspect, this application discloses a multi-core communication method based on hardware-assisted semaphores, including:

[0005] Parse the queue creation request initiated by the first subsystem to obtain the queue request information;

[0006] The target hardware auxiliary semaphore is determined from the preset semaphore state bitmap based on the queue request information; wherein, the preset semaphore state bitmap records the usage status of each hardware auxiliary semaphore;

[0007] Create a target remote procedure call communication queue and determine the queue metadata associated with the target hardware auxiliary semaphore and the target remote procedure call communication queue. Then, register the queue metadata to a lock-free hash table based on atomic operations to establish the binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue.

[0008] Based on the binding relationship, multi-core communication between the first subsystem and the second subsystem is completed through the target remote procedure call communication queue and the target hardware auxiliary semaphore.

[0009] Optionally, the target hardware auxiliary semaphore is determined from a preset semaphore state bitmap based on queue request information, including:

[0010] Parse the first identifier of the first subsystem and the second identifier of the second subsystem from the queue request information;

[0011] Verify whether the first identifier and the second identifier are within a preset valid range, and whether the first identifier and the second identifier are not equal;

[0012] Verify whether there is a hardware auxiliary semaphore in the preset semaphore status bitmap that is in an available state;

[0013] Verify whether the subsystem pair consisting of the first subsystem and the second subsystem satisfies the uniqueness discrimination condition;

[0014] If the first identifier and the second identifier are within a preset valid range, and the first identifier and the second identifier are not equal, and there is a hardware auxiliary semaphore in an available state in the preset semaphore state bitmap, and the subsystem pair consisting of the first subsystem and the second subsystem satisfies the uniqueness discrimination condition, then the target hardware auxiliary semaphore in an available state is determined from the preset semaphore state bitmap.

[0015] Optionally, before parsing the queue creation request initiated by the first subsystem, the following steps are also included:

[0016] Create a preset semaphore state bitmap; wherein the preset semaphore state bitmap contains several bits, each bit corresponding to the state of a hardware auxiliary semaphore, the state including available state and occupied state.

[0017] Optionally, the target hardware auxiliary semaphore in an available state is determined from a preset semaphore state bitmap, including:

[0018] The preset semaphore state bitmap is searched in the order from low bit to high bit.

[0019] The first available hardware auxiliary semaphore is used as the target hardware auxiliary semaphore.

[0020] Optionally, multi-core communication methods based on hardware-assisted semaphores also include:

[0021] Determine the remote procedure call communication load between the first subsystem and the second subsystem;

[0022] If the remote procedure call communication load is within a preset load threshold range, then the target remote procedure call communication queue is destroyed, the binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue is released, and the queue metadata is removed from the lock-free hash table.

[0023] Optionally, determine the remote procedure call communication load between the first subsystem and the second subsystem, including:

[0024] Statistical analysis of communication throughput and latency between the first and second subsystems;

[0025] The communication load of remote procedure calls is determined based on communication throughput and communication latency.

[0026] Optionally, registering queue metadata to a lock-free hash table based on atomic operations includes:

[0027] Determine the target bucket position in the lock-free hash table corresponding to the queue metadata, and read the current version number of the target bucket position;

[0028] Based on the compare and swap operation, the queue metadata is written to the target bucket location, and the current version number is updated to the target version number;

[0029] If the comparison and swap operation is successful, the queue metadata registration is considered successful.

[0030] If the comparison and swap operation fails, the registration operation will be re-executed or the current queue creation will be abandoned.

[0031] Secondly, this application discloses a multi-core communication device based on hardware-assisted semaphores, comprising:

[0032] The request parsing module is used to parse the queue creation request initiated by the first subsystem and obtain the queue request information;

[0033] The semaphore determination module is used to determine the target hardware auxiliary semaphore from a preset semaphore status bitmap based on queue request information; wherein, the preset semaphore status bitmap records the usage status of each hardware auxiliary semaphore;

[0034] The queue creation and binding module is used to create the target remote procedure call communication queue, determine the queue metadata related to the target hardware auxiliary semaphore and the target remote procedure call communication queue, and then register the queue metadata to the lock-free hash table based on atomic operations to establish the binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue.

[0035] The multi-core communication module is used to complete multi-core communication between the first subsystem and the second subsystem based on the binding relationship, through the target remote procedure call communication queue and the target hardware auxiliary semaphore.

[0036] Thirdly, this application discloses an electronic device, including:

[0037] Memory, used to store computer programs;

[0038] A processor for executing computer programs to implement the aforementioned disclosed multi-core communication method based on hardware-assisted semaphores.

[0039] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned multi-core communication method based on hardware-assisted semaphores.

[0040] As can be seen, this application proposes a multi-core communication method based on hardware-assisted semaphores, comprising: parsing a queue creation request initiated by a first subsystem to obtain queue request information; determining a target hardware-assisted semaphore from a preset semaphore state bitmap based on the queue request information; wherein the preset semaphore state bitmap records the usage status of each hardware-assisted semaphore; creating a target remote procedure call communication queue and determining queue metadata related to the target hardware-assisted semaphore and the target remote procedure call communication queue, and then registering the queue metadata to a lock-free hash table based on atomic operations to establish a binding relationship between the target hardware-assisted semaphore and the target remote procedure call communication queue; and completing multi-core communication between the first subsystem and the second subsystem through the target remote procedure call communication queue and the target hardware-assisted semaphore based on the binding relationship. As can be seen, this application identifies the queue metadata related to the target hardware auxiliary semaphore and the target remote procedure call communication queue, and then registers the queue metadata to a lock-free hash table based on atomic operations to establish a binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue. In this way, the unified management of the target hardware auxiliary semaphore and the target remote procedure call communication queue is realized, fundamentally avoiding the problem of asynchronous allocation and creation between the two. By recording the usage status of all hardware auxiliary semaphores through a preset semaphore status bitmap, semaphores can be accurately allocated based on actual communication needs, avoiding waste caused by long-term idle resources. The metadata registration is completed by combining atomic operations with a lock-free hash table, and the traditional lock mechanism is replaced by a lock-free method, which effectively improves the communication operation efficiency in a multi-core environment. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0042] Figure 1 This is a flowchart of a multi-core communication method based on hardware-assisted semaphores disclosed in this application;

[0043] Figure 2 This is a schematic diagram of a system architecture disclosed in this application;

[0044] Figure 3 This application discloses a flowchart of a dynamic scheduling process for an RPC communication queue.

[0045] Figure 4 This application discloses a flowchart of a lock-free hash table atomic update based on version number and CAS operation;

[0046] Figure 5 This is a schematic diagram of a multi-core communication device based on hardware-assisted semaphores disclosed in this application;

[0047] Figure 6 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0048] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] Traditional multi-core processor inter-core communication systems have significant problems in resource management: First, hardware auxiliary semaphores and communication queues are managed separately, which can easily lead to asynchronous allocation and creation of the two; second, a large number of hardware auxiliary semaphores are idle for a long time, resulting in a waste of hardware resources; third, the use of locking mechanisms to implement data transmission and reception of remote procedure call (RPC) queues will significantly reduce operating efficiency in a multi-core environment and seriously affect the real-time response capability of the inter-core communication system.

[0050] To address this, this application proposes a multi-core communication scheme based on hardware-assisted semaphores, which can avoid the problem of asynchronous allocation and creation of semaphores and queues; avoid the waste caused by long-term idle resources; effectively improve the communication efficiency in a multi-core environment; and ensure the real-time response capability of the system.

[0051] This application discloses a multi-core communication method based on hardware-assisted semaphores. See also... Figure 1 As shown, the method includes:

[0052] Step S11: Parse the queue creation request initiated by the first subsystem to obtain the queue request information.

[0053] In this embodiment, the first subsystem is the CPU (Central Processing Unit) subsystem in a multi-core processor architecture that initiates the inter-core communication queue creation request. It is the request initiator in multi-core communication and corresponds to the second subsystem, which is the communication receiver. In the inter-core communication scenario of a multi-core processor, the entire system is divided into multiple CPU subsystems, each with a unique identifier (the identifier value ranges from 1 to 255). The first subsystem establishes a remote procedure call (RPC) communication link with the second subsystem by initiating a queue creation request, enabling data interaction and instruction transmission between the cores. The queue request information is the set of inter-core communication parameters carried by the first subsystem when initiating the queue creation request. This information may include the first identifier of the first subsystem and the second identifier of the second subsystem, used to identify the initiator and receiver of the inter-core communication; it may also include other relevant requirements parameters for inter-core RPC communication.

[0054] Step S12: Determine the target hardware auxiliary semaphore from the preset semaphore state bitmap based on the queue request information; wherein, the preset semaphore state bitmap records the usage status of each hardware auxiliary semaphore.

[0055] In this embodiment, a preset semaphore state bitmap is first created. The preset semaphore state bitmap contains several bits, each bit corresponding to the state of a hardware auxiliary semaphore, including an available state and a occupied state. For example, if the system is configured with 256 hardware auxiliary semaphores, a corresponding 256-bit preset semaphore state bitmap is created. A bit of 0 indicates that the corresponding hardware auxiliary semaphore is in an available state, and a bit of 1 indicates that the corresponding hardware auxiliary semaphore is in an occupied state. Initially, all bits corresponding to the hardware auxiliary semaphores are set to 0, indicating that all hardware auxiliary semaphores are available for use.

[0056] In this embodiment, determining the target hardware auxiliary semaphore from a preset semaphore state bitmap based on queue request information includes: parsing the first identifier code of the first subsystem and the second identifier code of the second subsystem from the queue request information; verifying whether the first identifier code and the second identifier code are within a preset valid range and whether the first identifier code and the second identifier code are not equal; verifying whether there is a hardware auxiliary semaphore (HAS) in an available state in the preset semaphore state bitmap; verifying whether the subsystem pair composed of the first subsystem and the second subsystem satisfies the uniqueness discrimination condition; if the first identifier code and the second identifier code are within a preset valid range, and the first identifier code and the second identifier code are not equal, and there is a hardware auxiliary semaphore in an available state in the preset semaphore state bitmap, and the subsystem pair composed of the first subsystem and the second subsystem satisfies the uniqueness discrimination condition, then the target hardware auxiliary semaphore in an available state is determined from the preset semaphore state bitmap. It should be noted that the preset valid range refers to the value range of the subsystem's identifier code mentioned above; the uniqueness judgment condition means that the communication subsystem pair consisting of the first subsystem and the second subsystem has not created a corresponding RPC communication queue in the current multi-core communication system. That is, the combination of the source subsystem and the target subsystem is the first to initiate a queue creation request, thereby avoiding the problem of hardware resource idleness and inter-core communication link conflict caused by the same subsystem repeatedly creating communication queues; hardware auxiliary semaphores are a type of hardware semaphore. Hardware semaphores have the real-time performance of hardware interrupts and the task queuing mechanism, which can better solve the problem of inter-core communication.

[0057] In this embodiment, determining the target hardware auxiliary semaphore in an available state from a preset semaphore state bitmap includes: searching the preset semaphore state bitmap in a search order from low to high bits; and taking the first hardware auxiliary semaphore in an available state as the target hardware auxiliary semaphore. In some specific embodiments, the first identifier code is 10 and the second identifier code is 20, both of which are within the valid range of 1-255 and are not equal. There is an available semaphore in the bitmap, and the subsystem satisfies the uniqueness requirement for (10,20) as the first time a communication queue is created. Then, starting from the lowest bit (bit 0) of the bitmap, the 0th and 1st bits are both 1 (occupied state), and the 2nd bit is 0 (available state). Therefore, the hardware auxiliary semaphore corresponding to the 2nd bit is determined as the target hardware auxiliary semaphore.

[0058] Step S13: Create the target remote procedure call communication queue and determine the queue metadata related to the target hardware auxiliary semaphore and the target remote procedure call communication queue. Then, register the queue metadata to the lock-free hash table based on atomic operations to establish the binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue.

[0059] In this embodiment, creating a target remote procedure call communication queue includes: allocating contiguous memory space in a shared memory pool as a queue storage area based on the communication requirements between the first subsystem and the second subsystem, and initializing the memory space to obtain the target remote procedure call communication queue.

[0060] The queue metadata related to the target hardware auxiliary semaphore and the target remote procedure call communication queue includes: source subsystem ID (Identity Document), i.e., the first identification code, target subsystem ID, i.e., the second identification code, the identification ID of the target hardware auxiliary semaphore, the queue ID, etc.

[0061] In this embodiment, the queue metadata is registered to a lock-free hash table based on atomic operations to establish a binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue. This includes: determining the target bucket position corresponding to the queue metadata in the lock-free hash table and reading the current version number of the target bucket position; writing the queue metadata to the target bucket position based on a Compare And Swap (CAS) operation and updating the current version number to the target version number; if the CAS operation is successful, the queue metadata registration is considered successful; if the CAS operation fails, the registration operation is re-executed or the queue creation is abandoned. For example, taking a target hardware auxiliary semaphore ID of 2, a source subsystem ID of 10, and a target subsystem ID of 20 as an example, the system locates the 5th target bucket position in the lock-free hash table through hash calculation and reads the current version number of this bucket position as 3; then it initiates a CAS operation to attempt to write the queue metadata to the 5th bucket position and update the version number to 4; since there are no other concurrent write operations at present, the CAS operation is executed successfully, the metadata registration is completed, and the hardware auxiliary semaphore is officially bound to the RPC communication queue; if other cores simultaneously perform write operations on this bucket position during the CAS execution process, it will cause a version number mismatch, and the CAS operation will fail. At this time, the system will reread the latest version number and initiate the registration process again. In this way, the reliability of the binding relationship establishment in multi-core concurrent scenarios is ensured.

[0062] Step S14: Based on the binding relationship, multi-core communication between the first subsystem and the second subsystem is completed through the target remote procedure call communication queue and the target hardware auxiliary semaphore.

[0063] In this embodiment, multi-core communication between the first subsystem and the second subsystem is achieved based on the binding relationship and through the target remote procedure call communication queue and the target hardware auxiliary semaphore. Specifically, the first subsystem writes the RPC data to be transmitted into the communication queue bound to the target hardware auxiliary semaphore, and sends a synchronization notification to the second subsystem through the semaphore; after responding to the semaphore notification, the second subsystem reads the data from the corresponding communication queue according to the binding relationship and processes it, and can feed back the result through the semaphore after processing.

[0064] Furthermore, the remote procedure call (RPC) communication load between the first and second subsystems is determined. If the RPC communication load is within a preset load threshold range, the target RPC communication queue is destroyed, the binding relationship between the target hardware auxiliary semaphore and the target RPC communication queue is released, and the queue metadata is removed from the lock-free hash table. Determining the RPC communication load between the first and second subsystems includes: calculating the communication throughput and latency between the first and second subsystems; and determining the RPC communication load based on the communication throughput and latency. This ensures a balance between resource utilization and communication performance of the multi-core communication system under different load scenarios.

[0065] For example, assume the communication throughput between the first subsystem and the second subsystem is 50 frames / minute, the average communication latency is 8ms / frame, and the system's preset load calculation model is as follows: ( =0.6、 =0.4 is the weighting coefficient, T is the throughput, and D is the latency. Substituting the data, we can calculate P=0.6×(1 / 50)+0.4×8=0.012+3.2=3.21. Furthermore, if the system's preset load threshold range is [2,5], since the calculated communication load value of 3.21 is within this threshold range, it indicates that the current queue resource utilization rate has not reached the optimal level, which will trigger the resource reclamation process: destroy the corresponding target remote procedure call communication queue and release the shared memory space it occupies; unbind the target hardware auxiliary semaphore (such as ID 2) from the queue, and reset the corresponding bit of the semaphore to 0 (available state) in the preset semaphore status bitmap; finally, delete the metadata of the queue (including source subsystem ID=10, target subsystem ID=20, semaphore ID=2, etc.) from the lock-free hash table to complete the efficient reclamation and reuse of resources.

[0066] As can be seen, this application proposes a multi-core communication method based on hardware-assisted semaphores, comprising: parsing a queue creation request initiated by a first subsystem to obtain queue request information; determining a target hardware-assisted semaphore from a preset semaphore state bitmap based on the queue request information; wherein the preset semaphore state bitmap records the usage status of each hardware-assisted semaphore; creating a target remote procedure call communication queue and determining queue metadata related to the target hardware-assisted semaphore and the target remote procedure call communication queue, and then registering the queue metadata to a lock-free hash table based on atomic operations to establish a binding relationship between the target hardware-assisted semaphore and the target remote procedure call communication queue; and completing multi-core communication between the first subsystem and the second subsystem through the target remote procedure call communication queue and the target hardware-assisted semaphore based on the binding relationship. As can be seen, this application identifies the queue metadata related to the target hardware auxiliary semaphore and the target remote procedure call communication queue, and then registers the queue metadata to a lock-free hash table based on atomic operations to establish a binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue. In this way, the unified management of the target hardware auxiliary semaphore and the target remote procedure call communication queue is realized, fundamentally avoiding the problem of asynchronous allocation and creation between the two. By recording the usage status of all hardware auxiliary semaphores through a preset semaphore status bitmap, semaphores can be accurately allocated based on actual communication needs, avoiding waste caused by long-term idle resources. The metadata registration is completed by combining atomic operations with a lock-free hash table, and the traditional lock mechanism is replaced by a lock-free method, which effectively improves the communication operation efficiency in a multi-core environment.

[0067] As can be seen, this application discloses a multi-core communication resource management system and method based on hardware-assisted semaphores, which is applicable to efficient parallel communication scenarios among n (n≥2) CPU subsystems. Through integrated management, dynamic scheduling, and lock-free cooperation mechanisms, it solves the problems of consistency, resource utilization, and concurrency performance in traditional multi-core communication. The specific technical solution is as follows:

[0068] I. Overall Architecture Design

[0069] See Figure 2 As shown, this system adopts a layered architecture design, divided into an entity layer, a control layer, and a user layer from bottom to top. Each layer works together to achieve full lifecycle management of multi-core communication resources.

[0070] (1) Entity layer: includes a shared memory pool and a queue pool. The shared memory pool provides a dedicated physical storage area for RPC communication queues and supports dynamic allocation and release of memory resources; the queue pool stores all RPC communication queue instances in the system and serves as the basic carrier for inter-core data transmission. (2) Control layer: is the core management module of the architecture, integrating HAS_QueueManager (hardware-assisted semaphore-queue management class), semaphore bitmap, load monitoring module and active_queues lock-free hash table. Among them, HAS_QueueManager coordinates the core operations such as binding, creation and destruction of semaphores and queues; the load monitoring module counts the RPC communication load between CPU subsystems in real time and triggers dynamic queue scheduling; the active_queues lock-free hash table stores information of all currently active queues with "queue ID-queue metadata" as key-value pairs, ensuring efficient retrieval and updating in a multi-core environment. (3) User layer: consists of multiple CPU subsystems, which act as the initiator and receiver of inter-core communication. By initiating queue creation and destruction requests to the control layer, data interaction is completed with the help of RPC message queues to realize safe and orderly remote procedure calls.

[0071] II. Core Class Structure

[0072] Construct a unified semaphore-queue management class structure to ensure the atomicity and consistency of resource operations:

[0073] HAS_QueueManager, as the core management class, contains three key member variables: an atomic semaphore bitmap, used to mark the usage status of each hardware auxiliary semaphore in bit form; a lock-free hash table active_queues, which stores the metadata of all currently active queues with queue ID as the key and QueueEntry as the value; and an atomic queue ID generator next_queue_id, which ensures that the queue IDs generated in a multi-core environment are globally unique. HAS_QueueManager provides external interfaces such as `create_queue` and `destroy_queue` for queue creation and destruction, and internally encapsulates auxiliary methods such as `allocate_available_semaphore` for semaphore allocation, `is_valid_subsys` for subsystem validity verification, and `has_existing_pair` for subsystem uniqueness checks. `QueueEntry` serves as the queue metadata entry, storing core association information for a single RPC queue, including the source subsystem ID `src_subsys`, the target subsystem ID `dest_subsys`, the bound hardware auxiliary semaphore ID `sem_id`, the corresponding shared memory region `shm`, the atomic reference count `ref_count`, the version number `version`, and the bidirectional communication identifier `is_bidirectional`. `SharedMemoryRegion` describes the shared memory resources occupied by the RPC queue, including the memory starting address `address`, the memory size `size`, the region's unique ID `id`, and the name `name`. These three elements, through their association, form a complete integrated management structure of semaphore, queue, and shared memory, providing support for multi-core RPC communication.

[0074] III. Implementation Details

[0075] Figure 3 This application discloses a flowchart of a dynamic scheduling process for RPC communication queues. This process dynamically adjusts queue resources based on communication load: First, based on the communication throughput and latency within a preset time window, a load calculation model P=f(TD) is used (as can be seen from the foregoing embodiments, in some embodiments, this load model can be refined to...). The RPC communication load value P is quantified. Then, the load value P is compared with a preset threshold. If P is greater than the preset maximum threshold Pthmax, a queue creation process is triggered to allocate a new RPC communication queue and hardware auxiliary semaphore to the CPU subsystem with high load to improve inter-core communication capabilities. If P is less than the preset minimum threshold Pthmin, the current queue state is maintained and no resource adjustment operation is performed. If P is between Pthmin and Pthmax, a queue destruction process is triggered to release the underutilized RPC communication queue and the bound hardware auxiliary semaphore, and reclaim the relevant resources to the shared memory pool and semaphore bitmap to achieve efficient resource reuse. The entire process is executed in a loop, continuously monitoring and adjusting the queue state to ensure the performance of the multi-core communication system under different load scenarios.

[0076] Figure 4 This application discloses a flowchart of a lock-free hash table atomic update process based on version number and CAS operation. This process addresses the performance bottleneck of RPC message queue creation and destruction in high-concurrency scenarios by using a lock-free hash table combined with a version number mechanism to achieve thread-safe operation in a multi-core environment. Specifically, the requesting thread first reads the current version number of the target bucket location and checks it against the expected version number: if the version numbers match, it means there is no concurrent modification, so the queue metadata update operation is performed, and the version number is incremented to the new version number, followed by a Compare and Swap (CAS) atomic operation; if the version numbers do not match, a concurrent conflict is determined, and the process of abandoning the modification or retrying is directly initiated. After the CAS operation is executed, the update is checked again: if the update is successful, the registration or removal of queue metadata is completed, realizing the atomic change of the binding relationship between the RPC queue and the hardware auxiliary semaphore; if the update fails, it means that a concurrent write conflict occurred during the operation. At this time, the system can choose to reread the latest version number and initiate a retry, or directly abandon the operation to avoid deadlock and resource waste. In this way, the process completely avoids the performance bottlenecks and deadlock risks of traditional locking methods through version number verification and CAS atomic operations.

[0077] In summary, this solution achieves strong association management between hardware-assisted semaphores and their corresponding RPC communication queues by designing and implementing an atomic binding mechanism for semaphores and queues. Specifically, the hardware-assisted semaphores, RPC communication queues, and their related operation methods and member variables are uniformly encapsulated into a unified management class, HAS_QueueManager. This mechanism not only strictly guarantees the consistency of the message queue and semaphore's state throughout their entire lifecycle, including allocation, creation, and destruction, avoiding synchronization vulnerabilities caused by separate management, but also improves the queue's scalability through modular encapsulation. The HAS_QueueManager class contains three core member variables: First, Semaphore_bitmap, which uses each bit to correspond to the usage status of a hardware-assisted semaphore. Combined with the built-in function __builtin_ctz, it can quickly search for the lowest available semaphore in the current semaphore pool, providing efficient support for the creation of RPC communication queues. Second, Active_queues, implemented using a lock-free hash table, stores all currently active queues with queue IDs as keys and queue metadata as values. When a queue is created, new RPC message queue information is added to the pool; when a queue is destroyed, the corresponding information is removed from the pool, ensuring dynamic synchronization of queue resources. Third, Next_queue_id, a queue ID generator, can generate unique queue IDs in a multi-core environment. Combined with the semaphore bitmap, it can quickly locate the next available semaphore ID, ensuring the orderly and unique allocation of resources.

[0078] Furthermore, this embodiment also proposes a hardware-assisted semaphore timeout monitoring and automatic release mechanism. That is, a dedicated timeout threshold is configured for each bound semaphore, and the occupancy status of the semaphore is detected in real time by the monitoring thread of the control layer. If the semaphore occupies the threshold for a continuous time and there is no data interaction behavior, the semaphore unlocking operation will be automatically triggered to release its binding relationship with the queue and reset the bitmap state.

[0079] It should be noted that the above descriptions and definitions are only for the purpose of understanding the implementation of the present invention and are not intended to limit the present invention. Any modifications and changes made without departing from the spirit and scope of the present invention, especially the semaphore-queue atomic binding mechanism, the dynamic management method of RPC communication queue lifecycle, the method of creating RPC communication queues based on semaphore bitmaps, the atomic updating of inter-core communication RPC message queue IDs, and the creation and destruction of RPC queues in multi-CPU and multi-core systems by using lock-free hash tables combined with version numbers, are all within the protection scope of the present invention.

[0080] Accordingly, this application also discloses a multi-core communication device based on hardware-assisted semaphores, see [link to relevant documentation]. Figure 5 As shown, the device includes:

[0081] The request parsing module 11 is used to parse the queue creation request initiated by the first subsystem and obtain the queue request information;

[0082] The semaphore determination module 12 is used to determine the target hardware auxiliary semaphore from a preset semaphore status bitmap based on queue request information; wherein, the preset semaphore status bitmap records the usage status of each hardware auxiliary semaphore;

[0083] The queue creation and binding module 13 is used to create a target remote procedure call communication queue, determine the queue metadata related to the target hardware auxiliary semaphore and the target remote procedure call communication queue, and then register the queue metadata to a lock-free hash table based on atomic operations to establish the binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue.

[0084] The multi-core communication module 14 is used to complete multi-core communication between the first subsystem and the second subsystem based on the binding relationship, through the target remote procedure call communication queue and the target hardware auxiliary semaphore.

[0085] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0086] As can be seen, this application proposes a multi-core communication method based on hardware-assisted semaphores, comprising: parsing a queue creation request initiated by a first subsystem to obtain queue request information; determining a target hardware-assisted semaphore from a preset semaphore state bitmap based on the queue request information; wherein the preset semaphore state bitmap records the usage status of each hardware-assisted semaphore; creating a target remote procedure call communication queue and determining queue metadata related to the target hardware-assisted semaphore and the target remote procedure call communication queue, and then registering the queue metadata to a lock-free hash table based on atomic operations to establish a binding relationship between the target hardware-assisted semaphore and the target remote procedure call communication queue; and completing multi-core communication between the first subsystem and the second subsystem through the target remote procedure call communication queue and the target hardware-assisted semaphore based on the binding relationship. As can be seen, this application achieves integrated management of hardware-assisted semaphores and communication queues by establishing a binding relationship between the two, thus avoiding the problem of asynchronous allocation and creation at the source. By recording the usage status of all hardware-assisted semaphores through a preset semaphore status bitmap, semaphores can be accurately allocated based on actual communication needs, avoiding waste caused by long-term idle resources. Metadata registration is completed through atomic operations combined with a lock-free hash table, and the traditional lock mechanism is replaced by a lock-free approach, which effectively improves the communication efficiency in a multi-core environment and ensures the real-time response capability of the system.

[0087] Furthermore, embodiments of this application also provide an electronic device. Figure 6This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0088] Figure 6 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a display screen 23, an input / output interface 24, a communication interface 25, a power supply 26, and a communication bus 27. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the multi-core communication method based on hardware-assisted semaphores disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0089] In this embodiment, the power supply 26 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 25 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 24 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0090] Furthermore, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored thereon may include computer programs 221, and the storage method may be temporary storage or permanent storage. The computer programs 221 may include, in addition to computer programs capable of performing the hardware-assisted semaphore-based multi-core communication method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, computer programs capable of performing other specific tasks.

[0091] Furthermore, embodiments of this application also disclose a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed multi-core communication method based on hardware-assisted semaphores.

[0092] For the specific steps of this method, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0093] The various embodiments in this application are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. For the same or similar parts between the various embodiments, refer to each other. As for the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and relevant parts can be referred to in the method section.

[0094] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0095] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0096] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0097] The above provides a detailed description of a multi-core communication method, apparatus, device, and storage medium based on hardware-assisted semaphores provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A multi-core communication method based on hardware-assisted semaphores, characterized in that, include: Parse the queue creation request initiated by the first subsystem to obtain the queue request information; The target hardware auxiliary semaphore is determined from the preset semaphore state bitmap based on the queue request information; wherein the preset semaphore state bitmap records the usage status of each hardware auxiliary semaphore; A target remote procedure call communication queue is created, and queue metadata related to the target hardware auxiliary semaphore and the target remote procedure call communication queue is determined. Then, the queue metadata is registered to a lock-free hash table based on atomic operations to establish the binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue. Based on the binding relationship, multi-core communication between the first subsystem and the second subsystem is completed through the target remote procedure call communication queue and the target hardware auxiliary semaphore.

2. The multi-core communication method based on hardware-assisted semaphores according to claim 1, characterized in that, The step of determining the target hardware auxiliary semaphore from the preset semaphore state bitmap based on the queue request information includes: The first identifier of the first subsystem and the second identifier of the second subsystem are parsed from the queue request information; Verify whether the first identifier and the second identifier are within a preset valid range, and whether the first identifier and the second identifier are not equal; Verify whether the hardware auxiliary semaphore exists in the preset semaphore state bitmap in an available state; Verify whether the subsystem pair consisting of the first subsystem and the second subsystem satisfies the uniqueness discrimination condition; If the first identifier and the second identifier are within the preset valid range, and the first identifier and the second identifier are not equal, and there is a hardware auxiliary semaphore in the preset semaphore state bitmap that is in an available state, and the subsystem pair consisting of the first subsystem and the second subsystem satisfies the uniqueness discrimination condition, then the target hardware auxiliary semaphore in the available state is determined from the preset semaphore state bitmap.

3. The multi-core communication method based on hardware-assisted semaphores according to claim 2, characterized in that, Before parsing the queue creation request initiated by the first subsystem, the process also includes: Create the preset semaphore state bitmap; wherein the preset semaphore state bitmap contains several bits, each bit corresponding to the state of the hardware auxiliary semaphore, the state including an available state and an occupied state.

4. The multi-core communication method based on hardware-assisted semaphores according to claim 3, characterized in that, Determining the target hardware auxiliary semaphore in an available state from the preset semaphore state bitmap includes: The preset semaphore state bitmap is searched in a search order from low to high bits. The first available hardware auxiliary semaphore found in the search is taken as the target hardware auxiliary semaphore.

5. The multi-core communication method based on hardware-assisted semaphores according to claim 1, characterized in that, Also includes: Determine the remote procedure call communication load between the first subsystem and the second subsystem; If the remote procedure call communication load is within a preset load threshold range, then the target remote procedure call communication queue is destroyed, the binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue is released, and the queue metadata is removed from the lock-free hash table.

6. The multi-core communication method based on hardware-assisted semaphores according to claim 5, characterized in that, Determining the remote procedure call communication load between the first subsystem and the second subsystem includes: Statistical analysis of communication throughput and communication latency between the first subsystem and the second subsystem; The remote procedure call communication load is determined based on the communication throughput and the communication latency.

7. The multi-core communication method based on hardware-assisted semaphores according to any one of claims 1 to 6, characterized in that, The process of registering the queue metadata to a lock-free hash table based on atomic operations includes: Determine the target bucket position corresponding to the queue metadata in the lock-free hash table, and read the current version number of the target bucket position; Based on the comparison and swap operation, the queue metadata is written to the target bucket location, and the current version number is updated to the target version number; If the comparison and exchange operation is successful, then the queue metadata registration is considered successful. If the comparison and swap operation fails, the registration operation will be re-executed or the current queue creation will be abandoned.

8. A multi-core communication device based on hardware-assisted semaphores, characterized in that, include: The request parsing module is used to parse the queue creation request initiated by the first subsystem and obtain the queue request information; A semaphore determination module is used to determine a target hardware auxiliary semaphore from a preset semaphore state bitmap based on the queue request information; wherein the preset semaphore state bitmap records the usage status of each hardware auxiliary semaphore; The queue creation and binding module is used to create a target remote procedure call communication queue, determine the queue metadata related to the target hardware auxiliary semaphore and the target remote procedure call communication queue, and then register the queue metadata to a lock-free hash table based on atomic operations to establish the binding relationship between the target hardware auxiliary semaphore and the target remote procedure call communication queue. A multi-core communication module is used to complete multi-core communication between the first subsystem and the second subsystem based on the binding relationship, through the target remote procedure call communication queue and the target hardware auxiliary semaphore.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the hardware-assisted semaphore-based multi-core communication method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the multi-core communication method based on hardware-assisted semaphores as described in any one of claims 1 to 7.

Images