A heterogeneous nuclear spin lock implementation system and method

Abstract

This application provides a heterogeneous core spinlock implementation system and method. The system includes: a shared memory module for supporting atomic operation protocols of the architecture atomic operation unit; an ARM core module and a DSP core module, both used to complete initialization through the atomic operation unit, independently initiate lock requests through the architecture atomic operation unit and CAS logic processing unit, detect in real time whether the lock acquisition conditions are met based on the atomic operation unit, access shared resources based on the memory barrier control unit when the lock acquisition conditions are met, and independently release the lock through the atomic operation unit after completing the access to the shared resources; and an AXI bus interconnect module for realizing the interconnection between the dual cores and the shared memory module, which can adapt to the heterogeneous architecture of ARM cores and DSP cores, improve synchronization efficiency and reliability while ensuring fairness, and fully utilize the hardware performance of the dual cores.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a heterogeneous nuclear spinlock implementation system and method. Background Technology

[0002] In high-end embedded systems fields such as communication equipment, intelligent vehicles, industrial control, and aerospace, heterogeneous systems composed of ARM (Advanced RISC Machines) cores and DSP (Digital Signal Processor) cores have become the mainstream architecture due to their combination of strong control capabilities and efficient signal processing capabilities. Synchronous access to shared resources (such as shared memory and high-speed peripherals) between heterogeneous cores is crucial for ensuring system stability. Spinlocks, because they do not require core switching overhead, have become the preferred synchronization solution for scenarios with short lock holding times.

[0003] Existing heterogeneous core spinlock solutions have the following drawbacks: First, the core operation capabilities are unequal. Traditional solutions often rely on the ARM core to perform atomic operations, while the DSP core depends on the ARM core to complete lock acquisition / release. This results in high latency for DSP core lock operations and is prone to lock starvation due to ARM core priority contention. Second, there is insufficient fairness. Disordered contention mode or single-core-dominated scheduling logic cannot guarantee that dual cores acquire locks in the order of acquisition. Third, synchronization reliability is poor. The transmission latency of the AXI bus, the difference in consistency between dual-core caches, and instruction reordering optimization can easily lead to inconsistent lock state perception, causing shared resource access conflicts.

[0004] Therefore, existing fair lock schemes are either only applicable to homogeneous cores (dual-core atomic operation capabilities are consistent but not adapted to heterogeneous architectures), or require additional dedicated scheduling hardware (increasing complexity and cost), or do not fully utilize the hardware atomic operation capabilities of DSP cores (wasting hardware resources). Summary of the Invention

[0005] This application provides a heterogeneous nuclear spinlock implementation system and method.

[0006] A first aspect of this application provides a heterogeneous core spinlock implementation system, the system comprising an ARM core module, a DSP core module, an AXI bus interconnect module, and a shared memory module, wherein... The shared memory module, which is mounted on the AXI bus, is used to store preset bit ticket variables and supports atomic operation protocols of ARM architecture atomic operation units and DSP architecture atomic operation units. The ARM core module integrates an ARM architecture atomic operation unit, a first CAS logic processing unit, and a first memory barrier control unit. It is used to complete initialization through the ARM architecture atomic operation unit when the system starts up, independently initiate lock requests through the ARM architecture atomic operation unit and the first CAS logic processing unit, detect in real time whether the lock acquisition conditions are met based on the ARM architecture atomic operation unit, access shared resources based on the first memory barrier control unit when the lock acquisition conditions are met, and independently release the lock through the ARM architecture atomic operation unit after the shared resource access is completed. The DSP core module integrates a DSP architecture atomic operation unit, a second CAS logic processing unit, and a second memory barrier control unit. It is used to initialize the system through the DSP architecture atomic operation unit, independently initiate lock requests through the DSP architecture atomic operation unit and the second CAS logic processing unit, detect whether the lock acquisition conditions are met in real time based on the DSP architecture atomic operation unit, access the shared resources based on the second memory barrier control unit when the lock acquisition conditions are met, and independently release the lock through the DSP architecture atomic operation unit after the shared resource access is completed. The AXI bus interconnect module has a built-in bus arbitration unit that supports atomic transaction transmission and enables interconnection between dual-core and shared memory modules.

[0007] In an optional embodiment of this application, in the ARM core module, the initialization performed through the ARM architecture atomic operation unit includes the following steps: Divide the ticket variable currently loaded from the shared memory module into a high-order ticket stub and a low-order ticket number, and set both the high-order ticket stub and the low-order ticket number to 0. Initialize the atomic operation enable flag of the dual cores to be valid; Configure the atomic access timing parameters of the AXI bus. During the initialization process, the initialization core inserts two ARM write memory barrier instructions: the first ensures that the ticket variable is loaded, and the second ensures that the initialization state is synchronized to the shared memory module, so that the DSP core can accurately read the initial state through the AXI bus.

[0008] In an optional embodiment of this application, in the ARM core module, the step of independently initiating a lock request through the ARM architecture atomic operation unit and the first CAS logic processing unit includes the following steps: After the ARM core initiates a lock request, the ARM architecture atomic operation unit is used to execute the ARM load instruction to load the ticket variable from the shared memory module; The high-order ticket stub value of the ticket variable is extracted using the first CAS logic processing unit, and after being incremented by 1, the first updated ticket variable is determined. The first updated ticket variable includes the updated ticket stub and the initial ticket number. The first updated ticket variable is written back to the shared memory module via the ARM write-back instruction. If the write-back is successful, the ticket stub acquisition is completed. If the write-back fails, the load-update-write-back link is re-executed. After obtaining the ticket stub, it enters a spin wait state, and repeatedly reads the ticket number of the ticket variable in the shared memory module through the ARM load instruction, and determines whether the ticket stub it holds is equal to the read ticket number.

[0009] In an optional embodiment of this application, in the ARM core module, the ARM architecture-based atomic operation unit detects in real time whether the lock acquisition condition is met. If the lock acquisition condition is met, the shared resource is accessed based on the first memory barrier control unit, including the following steps: When the ARM architecture atomic operation unit detects that the ticket stub it holds is equal to the ticket number it reads, it uses the first memory barrier control unit to insert an ARM read memory barrier instruction to prevent subsequent shared resource read operations from being reordered before lock acquisition, ensuring that the latest shared resource data is read and the shared resource is accessed. During the access process, other cores are prohibited from preempting the lock.

[0010] In an optional embodiment of this application, in the ARM core module, the lock release is completed independently through the ARM architecture atomic operation unit, including the following steps: After completing the access to the shared resources, the first memory barrier control unit inserts an ARM write memory barrier instruction to ensure that all write operations to the shared resources have been refreshed to the shared memory module. The ticket variable is loaded using the ARM architecture atomic operation unit via the ARM load instruction, the low-order ticket number is extracted and incremented by 1, and the second updated ticket variable is determined. The second updated ticket variable is written back to the shared memory module via the ARM write-back instruction. If the write-back is successful, the lock is released, allowing the next core holding the ticket corresponding to the second updated ticket variable to detect that the ticket it holds is equal to the ticket number it read, thus triggering the lock acquisition process of the next core.

[0011] In an optional embodiment of this application, in the DSP core module, the initialization performed through the atomic operation unit of the DSP architecture includes the following steps: Divide the ticket variable currently loaded from the shared memory module into a high-order ticket stub and a low-order ticket number, and set both the high-order ticket stub and the low-order ticket number to 0. Initialize the atomic operation enable flag of the dual cores to be valid; Configure the atomic access timing parameters of the AXI bus. During the initialization process, the initialization core inserts two DSP write memory barrier instructions: the first ensures that the ticket variable is loaded, and the second ensures that the initialization state is synchronized to the shared memory module, so that the ARM core can accurately read the initial state through the AXI bus.

[0012] In an optional embodiment of this application, in the DSP core module, the step of independently initiating a lock request through the DSP architecture atomic operation unit and the second CAS logic processing unit includes the following steps: After the DSP core initiates a lock request, the DSP architecture atomic operation unit executes the DSP load instruction to load the ticket variable from the shared memory module; The high-order ticket stub value of the ticket variable is extracted using the second CAS logic processing unit, and after being incremented by 1, the third updated ticket variable is determined. The third updated ticket variable includes the updated ticket stub and the initial ticket number. The third updated ticket variable is written back to the shared memory module via the DSP write-back instruction. If the write-back is successful, the ticket stub acquisition is completed. If the write-back fails, the load-update-write-back link is re-executed. After obtaining the ticket stub, it enters a spin-wait state, continuously reading the ticket number from the ticket variable in the shared memory module through the loading instruction, and determining whether the ticket stub it holds is equal to the read ticket number.

[0013] In an optional embodiment of this application, in the DSP core module, the atomic operation unit based on the DSP architecture detects in real time whether the lock acquisition condition is met. If the lock acquisition condition is met, the shared resource is accessed based on the second memory barrier control unit, including the following steps: When the atomic operation unit of the DSP architecture detects that the ticket stub it holds is equal to the ticket number it reads, it uses the second memory barrier control unit to insert a DSP read memory barrier instruction to prevent subsequent shared resource read operations from being reordered before lock acquisition, ensuring that the latest shared resource data is read and the shared resource is accessed. During the access process, other cores are prohibited from preempting the lock.

[0014] In an optional embodiment of this application, in the DSP core module, the step of independently releasing the lock through atomic operation units of the DSP architecture includes the following steps: After completing the access to the shared resources, the second memory barrier control unit inserts a DSP write memory barrier instruction to ensure that all write operations to the shared resources have been refreshed to the shared memory module. Using the atomic operation unit of the DSP architecture, the ticket variable is loaded through the DSP loading instruction, the low-order ticket number is extracted and incremented by 1, and the ticket variable after the fourth update is determined. The fourth updated ticket variable is written back to the shared memory module via the DSP write-back instruction. If the write-back is successful, the lock is released, allowing the next core holding the ticket corresponding to the fourth updated ticket variable to detect that the ticket it holds is equal to the read ticket number, thus triggering the lock acquisition process of the next core.

[0015] A second aspect of this application provides a method for implementing heterogeneous nuclear spinlocks using the aforementioned heterogeneous nuclear spinlock implementation system, characterized in that it includes: Upon system startup, initialization is completed via ARM architecture atomic operation units or DSP architecture atomic operation units. The ARM architecture atomic operation unit and the first CAS logic processing unit of the ARM core module independently initiate a lock request. The ARM architecture atomic operation unit detects in real time whether the lock acquisition conditions are met. If the lock acquisition conditions are met, the shared resource is accessed based on the first memory barrier control unit. After the shared resource access is completed, the lock is released independently through the ARM architecture atomic operation unit. Lock requests are initiated independently by the DSP architecture atomic operation unit and the second CAS logic processing unit of the DSP core module. The DSP architecture atomic operation unit detects in real time whether the lock acquisition conditions are met. If the lock acquisition conditions are met, the shared resource is accessed based on the second memory barrier control unit. After the shared resource access is completed, the lock is released independently by the DSP architecture atomic operation unit.

[0016] Compared with the prior art, the technical solutions provided in this application have at least some or all of the following advantages: The heterogeneous core spinlock implementation system described in this application includes an ARM core module, a DSP core module, an AXI bus interconnect module, and a shared memory module. The shared memory module, mounted on the AXI bus, stores preset bit ticket variables and supports atomic operation protocols for both ARM and DSP architecture atomic operation units. The ARM core module integrates an ARM architecture atomic operation unit, a first CAS logic processing unit, and a first memory barrier control unit. Upon system startup, it initializes via the ARM architecture atomic operation unit, independently initiates lock requests via the ARM architecture atomic operation unit and the first CAS logic processing unit, continuously checks whether lock acquisition conditions are met based on the ARM architecture atomic operation unit, accesses shared resources based on the first memory barrier control unit when lock acquisition conditions are met, and independently releases the lock via the ARM architecture atomic operation unit after accessing the shared resources. The DSP core module integrates a DSP architecture atomic operation unit, a second CAS logic processing unit, and a second memory barrier control unit. Upon system startup, it initializes via the DSP architecture atomic operation unit, independently initiates lock requests via the DSP architecture atomic operation unit and the second CAS logic processing unit, continuously checks whether lock acquisition conditions are met based on the DSP architecture atomic operation unit, accesses shared resources via the second memory barrier control unit when lock acquisition conditions are met, and independently releases the lock via the DSP architecture atomic operation unit after accessing the shared resources. The AXI bus interconnect module, with its built-in bus arbitration unit, supports atomic transaction transmission, enabling interconnection between the dual-core and shared memory modules. It is compatible with heterogeneous architectures of ARM cores and DSP cores, providing a ticket-based fair spinlock solution based on dual-core atomic operations. This ensures fairness while improving synchronization efficiency and reliability, fully leveraging the hardware performance of the dual cores. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of the structure of a heterogeneous nuclear spinlock implementation system provided in one embodiment of this application; Figure 2 A schematic diagram illustrating the process of independently initiating a lock request using dual cores, as provided in one embodiment of this application; Figure 3 A schematic diagram illustrating the process of independently releasing the lock in each of the two cores, as provided in one embodiment of this application; Figure 4 A flowchart illustrating a heterogeneous nuclear spinlock implementation method provided in one embodiment of this application; Figure 5 This is a schematic diagram of a computer device structure provided in one embodiment of this application. Detailed Implementation

[0018] In the process of developing this application, the inventors discovered that current heterogeneous nuclear spinlock schemes are inferior in terms of core operational capability equivalence, fairness, and synchronization reliability.

[0019] To address the aforementioned issues, this application provides a heterogeneous nuclear spinlock implementation system and method to improve the equivalence, fairness, and synchronization reliability of the core operational capabilities of heterogeneous nuclear spinlocks.

[0020] The solutions in this application embodiment can be implemented using various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.

[0021] To make the technical solutions and advantages of the embodiments of this application clearer, the exemplary embodiments of this application will be described in further detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not an exhaustive list of all embodiments. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0022] Please see Figure 1 The heterogeneous core spinlock implementation system provided in this application includes an ARM core module, a DSP core module, an AXI bus interconnect module, and a shared memory module. The shared memory module, which is mounted on the AXI bus, is used to store preset bit ticket variables and supports atomic operation protocols of ARM architecture atomic operation units and DSP architecture atomic operation units. The ARM core module integrates an ARM architecture atomic operation unit, a first CAS logic processing unit, and a first memory barrier control unit. It is used to complete initialization through the ARM architecture atomic operation unit when the system starts up, independently initiate lock requests through the ARM architecture atomic operation unit and the first CAS logic processing unit, detect in real time whether the lock acquisition conditions are met based on the ARM architecture atomic operation unit, access shared resources based on the first memory barrier control unit when the lock acquisition conditions are met, and independently release the lock through the ARM architecture atomic operation unit after the shared resource access is completed. The DSP core module integrates a DSP architecture atomic operation unit, a second CAS logic processing unit, and a second memory barrier control unit. It is used to initialize the system through the DSP architecture atomic operation unit, independently initiate lock requests through the DSP architecture atomic operation unit and the second CAS logic processing unit, detect whether the lock acquisition conditions are met in real time based on the DSP architecture atomic operation unit, access the shared resources based on the second memory barrier control unit when the lock acquisition conditions are met, and independently release the lock through the DSP architecture atomic operation unit after the shared resource access is completed. The AXI bus interconnect module has a built-in bus arbitration unit that supports atomic transaction transmission and enables interconnection between dual-core and shared memory modules.

[0023] In an optional embodiment of this application, in the heterogeneous core spinlock implementation system of this application, the shared memory module core can store a 32-bit ticket variable (fixed address, such as 0x40000000), supporting the AXI4-ATOP atomic operation protocol (AXI4-ATOP is a mechanism in the AXI4 protocol used to support atomic operations, allowing indivisible read-modify-write operations on memory in multi-core or multi-processor systems; the AXI4 protocol implements this function by defining two main types of atomic operations); the ARM architecture atomic operation unit supports LDREX / STREX instruction pairs (LDREX (Load Exclusive) instruction is used to load a value from memory into a register, while marking the memory address as "exclusive access". This operation notifies the processor's Exclusive Monitor that the processor is currently accessing the memory address. STREX (Store Exclusive) instruction is used to attempt to write a value back to the memory address); the memory barrier control unit supports DMB / DSB instructions (DMB (Data Memory Barrier), DSB (Data... SynchronizationBarrier (data synchronization barrier); the DSP architecture atomic operation unit supports dedicated atomic instructions such as LDXA / STXA (LDXA is an abbreviation for Load-Exclusive instruction, and STXA is an abbreviation for Store-Exclusive instruction); the memory barrier control unit supports memory barrier instructions adapted to the DSP architecture; and the bus arbitration unit supports medium-priority arbitration.

[0024] The heterogeneous core spinlock implementation system of this application features dual-core atomic operation adaptation: the ARM core uses LDREX / STREX instruction pairs to implement 32-bit atomic read and write, while the DSP core uses its architecture-specific atomic instructions (such as LDXA / STXA of the multi-core digital signal processor (DSP) TI C66x, and the atomic operation function atomic_add of the high-performance 32-bit floating-point digital signal processor (DSP) ADI SHARC), ensuring that both cores have hardware-level atomic operation capabilities; the atomic operations of both cores are encapsulated into atomic transactions through the AXI4-ATOP protocol, and the atomicity of the transactions is guaranteed by the AXI bus, which can avoid concurrency conflicts.

[0025] In an optional embodiment of this application, in the ARM core module, the initialization performed through the ARM architecture atomic operation unit includes the following steps: Divide the ticket variable currently loaded from the shared memory module into a high-order ticket stub and a low-order ticket number, and set both the high-order ticket stub and the low-order ticket number to 0. Initialize the atomic operation enable flag of the dual cores to be valid; Configure the atomic access timing parameters of the AXI bus. During the initialization process, the initialization core inserts two ARM write memory barrier instructions: the first ensures that the ticket variable is loaded, and the second ensures that the initialization state is synchronized to the shared memory module, so that the DSP core can accurately read the initial state through the AXI bus.

[0026] In an optional embodiment of this application, in the DSP core module, the initialization performed through the atomic operation unit of the DSP architecture includes the following steps: Divide the ticket variable currently loaded from the shared memory module into a high-order ticket stub and a low-order ticket number, and set both the high-order ticket stub and the low-order ticket number to 0. Initialize the atomic operation enable flag of the dual cores to be valid; Configure the atomic access timing parameters of the AXI bus. During the initialization process, the initialization core inserts two DSP write memory barrier instructions: the first ensures that the ticket variable is loaded, and the second ensures that the initialization state is synchronized to the shared memory module, so that the ARM core can accurately read the initial state through the AXI bus.

[0027] In an optional embodiment of this application, when the heterogeneous core spinlock implementation system starts, initialization can be completed by an ARM core or a DSP core (ARM core by default) through atomic operations: the high 16 bits of the 32-bit ticket variable (next_ticket) and the low 16 bits of the ticket number (current_ticket) are both set to 0; the atomic operation enable flag of the dual cores is initialized to be valid; and the atomic access timing parameters of the AXI bus (such as atomic transaction timeout and arbitration priority) are configured. During the initialization process, the initialization core needs to insert two write memory barrier instructions: the first ensures that the ticket variable is loaded, and the second ensures that the initialization state is synchronized to the shared memory, so that the other core can accurately read the initial state through the AXI bus.

[0028] The 32-bit ticket variable format is defined as follows: bits 31 to 16 are the ticket stub (unsigned 16 bits, value 0 to 65535), and bits 15 to 0 are the ticket number (unsigned 16 bits, value 0 to 65535). It supports modulo 65536 looping. When the ticket stub / ticket number increments to 65535, the next increment will automatically reset to zero (65535+1=0) to avoid ticket overflow.

[0029] In an optional embodiment of this application, in the ARM core module, the step of independently initiating a lock request through the ARM architecture atomic operation unit and the first CAS logic processing unit includes the following steps: After the ARM core initiates a lock request, the ARM architecture atomic operation unit is used to execute the ARM load instruction to load the ticket variable from the shared memory module; The high-order ticket stub value of the ticket variable is extracted using the first CAS logic processing unit, and after being incremented by 1, the first updated ticket variable is determined. The first updated ticket variable includes the updated ticket stub and the initial ticket number. The first updated ticket variable is written back to the shared memory module via the ARM write-back instruction. If the write-back is successful, the ticket stub acquisition is completed. If the write-back fails, the load-update-write-back link is re-executed. After obtaining the ticket stub, it enters a spin wait state, and repeatedly reads the ticket number of the ticket variable in the shared memory module through the ARM load instruction, and determines whether the ticket stub it holds is equal to the read ticket number.

[0030] In an optional embodiment of this application, in the DSP core module, the step of independently initiating a lock request through the DSP architecture atomic operation unit and the second CAS logic processing unit includes the following steps: After the DSP core initiates a lock request, the DSP architecture atomic operation unit executes the DSP load instruction to load the ticket variable from the shared memory module; The high-order ticket stub value of the ticket variable is extracted using the second CAS logic processing unit, and after being incremented by 1, the third updated ticket variable is determined. The third updated ticket variable includes the updated ticket stub and the initial ticket number. The third updated ticket variable is written back to the shared memory module via the DSP write-back instruction. If the write-back is successful, the ticket stub acquisition is completed. If the write-back fails, the load-update-write-back link is re-executed. After obtaining the ticket stub, it enters a spin-wait state, continuously reading the ticket number from the ticket variable in the shared memory module through the loading instruction, and determining whether the ticket stub it holds is equal to the read ticket number.

[0031] In an optional embodiment of this application, see [link to relevant documentation]. Figure 2 Both cores independently initiate lock requests through their own atomic operations, with a symmetrical and equivalent process: (1) ARM core lock request: After the ARM core initiates a lock request, the atomic operation unit executes the LDREXW instruction (32-bit atomic load) to load the 32-bit ticket variable from the shared memory; the CAS logic processing unit extracts the high 16 bits of the ticket value, increments it by 1, and reconstructs the 32-bit ticket variable (the high 16 bits are the updated ticket, and the low 16 bits keep the original ticket number); the updated ticket variable is written back to the shared memory through the STREXW instruction (32-bit atomic write back). If the write back is successful, the ticket acquisition is completed (e.g., if the initial ticket is 0, it will be 1 after acquisition). If it fails, the "load-update-write back" link is re-executed; then the ARM core enters a spin wait state and reads the low 16 bits of the ticket number of the ticket variable through the LDREXW instruction in a loop to determine whether the ticket held by itself is equal to the ticket number.

[0032] (2) DSP core lock application: After the DSP core initiates a lock application, the atomic operation unit executes the DSP-specific atomic load instruction (such as LDXA) to load the 32-bit ticket variable from the shared memory via the AXI bus; the CAS logic processing unit extracts the high 16-bit ticket value and increments it by 1 to construct the updated 32-bit ticket variable; the updated ticket variable is written back to the shared memory via the AXI bus through the DSP-specific atomic write-back instruction (such as STXA). If successful, the ticket stub acquisition is completed (e.g., the value is 2 after acquisition); if it fails, it is retried; then the DSP core enters a spin wait state and reads the low 16-bit ticket number of the ticket variable through the AXI bus in a loop through atomic operations to determine whether the ticket stub it holds is equal to the ticket number.

[0033] The heterogeneous core spinlock implementation system of this application is optimized through the CAS mechanism: the CAS logic of both cores adopts a closed-loop link of "load-compare-update-writeback". If the writeback operation fails (indicating that other cores are operating on the ticket variable at the same time), it will be retried immediately without entering the spin wait, which can improve the efficiency of ticket variable operation; at the same time, the arbitration mechanism of the AXI bus ensures the orderly execution of atomic transactions of the two cores.

[0034] In an optional embodiment of this application, in the ARM core module, the ARM architecture-based atomic operation unit detects in real time whether the lock acquisition condition is met. If the lock acquisition condition is met, the shared resource is accessed based on the first memory barrier control unit, including the following steps: When the ARM architecture atomic operation unit detects that the ticket stub it holds is equal to the ticket number it reads, it uses the first memory barrier control unit to insert an ARM read memory barrier instruction to prevent subsequent shared resource read operations from being reordered before lock acquisition, ensuring that the latest shared resource data is read and the shared resource is accessed. During the access process, other cores are prohibited from preempting the lock.

[0035] In an optional embodiment of this application, in the DSP core module, the atomic operation unit based on the DSP architecture detects in real time whether the lock acquisition condition is met. If the lock acquisition condition is met, the shared resource is accessed based on the second memory barrier control unit, including the following steps: When the atomic operation unit of the DSP architecture detects that the ticket stub it holds is equal to the ticket number it reads, it uses the second memory barrier control unit to insert a DSP read memory barrier instruction to prevent subsequent shared resource read operations from being reordered before lock acquisition, ensuring that the latest shared resource data is read and the shared resource is accessed. During the access process, other cores are prohibited from preempting the lock.

[0036] In an optional embodiment of this application, when the ticket stub held by the core is equal to the ticket number of the ticket variable, the lock acquisition logic is triggered, and the dual-core operation is symmetrical: (1) ARM core: After detecting that ticket stub = ticket number, the memory barrier control unit inserts a read memory barrier instruction (such as DMB) to prevent subsequent shared resource read operations from being reordered before lock acquisition, ensuring that the latest shared resource data is read; then it starts accessing the shared resource, and other cores are prohibited from preempting the lock during the access process (protected by the ticket variable state).

[0037] (2) DSP core: After detecting that ticket stub = ticket number, the memory barrier control unit inserts a read memory barrier instruction adapted to the DSP architecture to prevent subsequent shared resource read operations from being reordered; optionally, a lock acquisition confirmation signal is sent to the ARM core through the AXI bus, and the ARM core returns a confirmation response after verifying the ticket variable status through atomic operations to ensure that the lock status perception of the two cores is consistent; then the DSP core begins to access the shared resources.

[0038] In an optional embodiment of this application, in the ARM core module, the lock release is completed independently through the ARM architecture atomic operation unit, including the following steps: After completing the access to the shared resources, the first memory barrier control unit inserts an ARM write memory barrier instruction to ensure that all write operations to the shared resources have been refreshed to the shared memory module. The ticket variable is loaded using the ARM architecture atomic operation unit via the ARM load instruction, the low-order ticket number is extracted and incremented by 1, and the second updated ticket variable is determined. The second updated ticket variable is written back to the shared memory module via the ARM write-back instruction. If the write-back is successful, the lock is released, allowing the next core holding the ticket corresponding to the second updated ticket variable to detect that the ticket it holds is equal to the ticket number it read, thus triggering the lock acquisition process of the next core.

[0039] In an optional embodiment of this application, in the DSP core module, the step of independently releasing the lock through atomic operation units of the DSP architecture includes the following steps: After completing the access to the shared resources, the second memory barrier control unit inserts a DSP write memory barrier instruction to ensure that all write operations to the shared resources have been refreshed to the shared memory module. Using the atomic operation unit of the DSP architecture, the ticket variable is loaded through the DSP loading instruction, the low-order ticket number is extracted and incremented by 1, and the ticket variable after the fourth update is determined. The fourth updated ticket variable is written back to the shared memory module via the DSP write-back instruction. If the write-back is successful, the lock is released, allowing the next core holding the ticket corresponding to the fourth updated ticket variable to detect that the ticket it holds is equal to the read ticket number, thus triggering the lock acquisition process of the next core.

[0040] In an optional embodiment of this application, see [link to relevant documentation]. Figure 3 Both cores independently release the lock through their own atomic operations. The core operation is to atomically increment the ticket number, allowing the core corresponding to the next ticket stub to acquire the lock. (1) ARM core releases lock: After completing the access to the shared resource, first insert a write memory barrier instruction (such as DMB) to ensure that all write operations to the shared resource have been refreshed to the shared memory; load the ticket variable through the LDREXW instruction, extract the lower 16 bits of the ticket number and increment it by 1 to construct the updated ticket variable; atomically write the updated ticket variable back to the shared memory through the STREXW instruction. If the write back is successful, the lock is released; after the ticket number is updated, the next core (ARM core or DSP core) holding the corresponding ticket stub can detect that the ticket stub = ticket number and trigger the lock acquisition process.

[0041] (2) DSP core releases lock: After completing the access to the shared resource, first insert the write memory barrier instruction adapted to the DSP architecture to ensure that the write operation on the shared resource is completed; load the ticket variable through the AXI bus via the atomic load instruction, extract the lower 16 bits of the ticket number and increment it by 1 to construct the updated ticket variable; atomically write the updated ticket variable back to the shared memory through the AXI bus via the atomic write-back instruction, and the lock release is completed if successful; optionally, send the lock release notification to the ARM core through the AXI bus to ensure the lock state synchronization of the two cores.

[0042] In the heterogeneous core spinlock implementation system of this application, memory barriers are inserted at the following key nodes for both cores: ① Before the ticket variable is loaded: ensure that the address is read completely; ② After the ticket stub is acquired: ensure that the ticket stub value is synchronized; ③ After the lock is successfully acquired: insert a read memory barrier to ensure read consistency of shared resources; ④ Before the lock is released: insert a write memory barrier to ensure write consistency of shared resources; ⑤ After the ticket number is updated: ensure that the ticket number state is synchronized. Through fine-grained memory barriers, the instruction reordering and cache consistency problems caused by the differences in dual-core architecture are solved.

[0043] In an optional embodiment of this application, a ticket overflow protection unit is built into the shared memory module. This ticket overflow protection unit monitors the values ​​of ticket stubs and ticket numbers in real time. When the ticket stub or ticket number is detected to increase to 65535, a modulo 65536 operation is automatically triggered, and the value after the next increment is 0. At the same time, the number of overflows is recorded for system debugging and ticket overflow protection to ensure the ticket mechanism remains available.

[0044] The heterogeneous core spinlock implementation system of this application realizes a fair spinlock for heterogeneous ARM and DSP core systems through a collaborative architecture of "dual-core peer-to-peer atomic operations + ticket-based fair scheduling + AXI bus atomic interconnection". This allows the dual cores to have independent lock operation capabilities, eliminates lock starvation, improves synchronization efficiency and reliability, and fully leverages the performance advantages of heterogeneous hardware. At the same time, it has wide adaptability and low hardware complexity, and can be widely used in heterogeneous computing scenarios with high requirements for fairness and real-time performance, such as intelligent vehicles and industrial control, and has important engineering application value.

[0045] This application's heterogeneous core spinlock implementation system addresses the problems of poor fairness, lock starvation, and high overhead of invalid spins in existing heterogeneous core (ARM+DSP) spinlocks, as well as the issues of unequal core operations, insufficient fairness, and poor reliability in existing heterogeneous core spinlocks. It provides a fair heterogeneous core spinlock implementation scheme based on AXI bus atomic operations for dual-core systems. By allowing both the ARM and DSP cores to independently complete lock operations based on their own hardware atomic operations, CAS mechanisms, and memory barrier technology, and combining the "ticket stub-ticket number" fairness mechanism of 32-bit ticket variables with the atomic access characteristics of the AXI bus, it achieves equal, fair, and reliable synchronization between the two cores, improving the overall performance of the heterogeneous system.

[0046] In an optional embodiment of this application, the heterogeneous nuclear spinlock implementation system further includes a data plane development kit (DPDK) module and a PTP protocol implementation tool (ptp4l) module, wherein, The DPDK module provides high-speed user-space packet processing capabilities and enables efficient data transfer between different cores through a lock-free circular buffer. The ptp4l module is responsible for network time synchronization, providing a unified nanosecond-level time base for each core.

[0047] The heterogeneous core spinlock implementation system of this application ensures the atomicity of shared resource access through heterogeneous core spinlocks, realizes efficient data transfer between different cores through the DPDK module, and provides nanosecond-level unified time base for each core through the ptp4l module. This allows data to be received from the network interface and distributed to different cores for processing via DPDK. During processing, timestamps are used to ensure timing correctness, while the spinlock mechanism prevents conflicts from concurrent access by multiple cores. Ultimately, this achieves a cross-core data transmission solution with high throughput, low latency, and strong consistency.

[0048] In an optional embodiment of this application, the unified time base in the ptp4l module is determined through the following steps: Register the kernel virtual interface of the kernel network interface in the DPDK framework, so as to use the PTP protocol implementation tool to receive the first PTP packet received by DPDK user space from the kernel virtual interface, and forward the first PTP packet to the kernel protocol stack. Extract the hardware receive timestamp of the first PTP packet, and while the PTP protocol implementation tool receives the first PTP packet from the kernel virtual port, read the hardware receive timestamp corresponding to the first PTP packet. After DPDK calls the kernel virtual interface to send the first PTP packet, it extracts the hardware transmission timestamp of the first packet and uses the kernel virtual interface to read the hardware transmission timestamp, so that the PTP protocol implementation tool can obtain the hardware transmission timestamp. The PTP protocol implementation tool determines the time offset based on the obtained hardware transmit timestamp and hardware receive timestamp, and adjusts the hardware clock of the DPDK network card according to the time offset. The adjusted clock is a unified time base.

[0049] In an optional embodiment of this application, in the kernel virtual interface of the kernel network interface registered in the DPDK framework, the packet forwarding rules of the kernel virtual interface are configured to forward packets conforming to the preset PTP protocol format as the first PTP packet to the kernel protocol stack.

[0050] In an optional embodiment of this application, before receiving the first PTP packet received from the kernel virtual port by the DPDK user space using the PTP protocol implementation tool, the method further includes: The newly added PTP packet identification module in the DPDK framework is used to detect whether the first received PTP packet is a PTP packet; If the received message is a PTP message, the current message is taken as the first PTP message, and the step of receiving the first PTP message received by DPDK user space from the kernel virtual port using the PTP protocol implementation tool is executed. No response is received if the received message is not a PTP message.

[0051] In an optional embodiment of this application, the step of extracting the hardware receive timestamp of the first PTP packet and reading the hardware receive timestamp corresponding to the first PTP packet while the PTP protocol implementation tool receives the first PTP packet from the kernel virtual port includes: Call the hardware timestamp retrieval function provided by the DPDK network card driver to extract the hardware receive timestamp of the first PTP packet; Write the extracted hardware receive timestamp into the extended field of the structure in the DPDK message buffer; The message buffer is converted into a kernel socket buffer. During the conversion, the receive timestamp in the extended field of the message buffer structure is synchronized to the timestamp field of the kernel socket buffer. This allows the PTP protocol implementation tool to read the hardware receive timestamp corresponding to the first PTP message while receiving the first PTP message from the kernel virtual port.

[0052] In an optional embodiment of this application, the step of extracting the hardware transmission timestamp of the first PTP packet after DPDK calls the kernel virtual interface to send the first PTP packet, and reading the hardware transmission timestamp using the kernel virtual interface so that the PTP protocol implementation tool can obtain the hardware transmission timestamp, includes: After DPDK calls the kernel virtual interface to send the first PTP packet, it calls the hardware transmission timestamp acquisition function to extract the hardware transmission timestamp of the first packet. A shared memory region between the DPDK user space and the kernel virtual interface kernel space is pre-created. The extracted hardware transmission timestamp is written into this shared memory, and the PTP packet identifier corresponding to the hardware transmission timestamp is marked. After the kernel virtual interface sends the first PTP packet, a loop detection mechanism is started to read the hardware transmission timestamp corresponding to the first PTP packet from the shared memory. If the loop detection duration reaches a preset threshold, it is determined whether the kernel virtual interface has read the hardware transmission timestamp. If the kernel virtual interface fails to read the hardware transmission timestamp, the current timestamp acquisition process will be terminated, and a timeout log will be recorded. If the kernel virtual interface reads the hardware transmission timestamp, it calls a kernel function to generate a message carrying the hardware transmission timestamp and sends the message to the error queue, so that the PTP protocol implementation tool can obtain the hardware transmission timestamp by listening to the error queue.

[0053] In an optional embodiment of this application, after determining the time offset using the PTP protocol implementation tool based on the obtained hardware transmission timestamp and hardware reception timestamp, the method further includes: Based on the time offset, a time adjustment instruction is generated, and a virtual PTP device is registered in the kernel virtual interface kernel mode. This PTP device is bound to the hardware clock of the actual DPDK network card. The adjustment of the hardware clock of the DPDK network card based on the time offset includes: After the virtual PTP device receives the time adjustment command, it calls the network card hardware time writing interface provided by DPDK to complete the adjustment of the hardware clock of the DPDK network card.

[0054] In an optional embodiment of this application, the time offset is determined using the PTP protocol implementation tool based on the obtained hardware transmission timestamp and hardware reception timestamp, through the following expression: δ=((t4-t3)+(t2-t1)) / 2 Where t1 is the time when the physical network interface card (NIC) hardware sends the first PTP packet to the DPDK user space, t2 is the hardware reception timestamp, t3 is the hardware transmission timestamp, and t4 is the time when the physical NIC hardware receives the first PTP packet sent from the DPDK user space. The step of calling the network card hardware time writing interface provided by DPDK to adjust the hardware clock of the DPDK network card includes: using the PTP protocol implementation tool to open the registered virtual PTP device, calling the corresponding operation interface to modify the network card time deviation according to the time offset in the time adjustment instruction.

[0055] Please see Figure 4 One embodiment of this application provides a method for implementing heterogeneous nuclear spinlocks using the above-described heterogeneous nuclear spinlock implementation system, comprising: The S410 initializes itself via an ARM architecture atomic operation unit or a DSP architecture atomic operation unit during system startup. S420 independently initiates a lock request through the ARM architecture atomic operation unit and the first CAS logic processing unit of the ARM core module. Based on the ARM architecture atomic operation unit, it detects in real time whether the lock acquisition conditions are met. If the lock acquisition conditions are met, it accesses the shared resource based on the first memory barrier control unit. After completing the access to the shared resource, it independently releases the lock through the ARM architecture atomic operation unit. S430 independently initiates a lock request through the DSP architecture atomic operation unit and the second CAS logic processing unit of the DSP core module. Based on the DSP architecture atomic operation unit, it detects in real time whether the lock acquisition conditions are met. If the lock acquisition conditions are met, it accesses the shared resource based on the second memory barrier control unit. After completing the access to the shared resource, it independently releases the lock through the DSP architecture atomic operation unit.

[0056] The heterogeneous core spinlock implementation method of this application constructs a collaborative architecture of "dual-core peer-to-peer atomic operations + ticket-based fair scheduling + AXI bus atomic interconnection". A 32-bit ticket variable serves as the core of fair scheduling. Both cores independently complete ticket stub acquisition, ticket number verification, and ticket number update through their own hardware atomic operations. The CAS mechanism is used to ensure the atomicity of ticket variable operations, avoiding concurrent conflicts. Memory barriers are used to solve instruction reordering and cache consistency issues. The AXI bus, which supports atomic operations, ensures consistent access to shared ticket variables by both cores. Ultimately, this achieves fair lock acquisition by both cores in the order of application, eliminating lock starvation and improving synchronization efficiency.

[0057] It should be understood that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order constraint on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the diagram may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0058] For specific limitations on the above method, please refer to the limitations on heterogeneous nuclear spinlock implementation systems mentioned above, which will not be repeated here.

[0059] In one embodiment, a computer device is provided, the internal structure of which can be as follows: Figure 5 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described heterogeneous nuclear spinlock implementation method. It includes: a memory and a processor; the memory stores a computer program; and the processor executes the computer program to implement any step in the above-described heterogeneous nuclear spinlock implementation method.

[0060] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, can implement any of the steps in the heterogeneous nuclear spinlock implementation method described above.

[0061] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application 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.

[0062] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. 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 processor, 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... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0063] 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.

[0064] 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.

[0065] Although preferred embodiments of this application 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 the preferred embodiments as well as all changes and modifications falling within the scope of this application.

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

Claims

1. A heterogeneous nuclear spin-locking implementation system, characterized in that, The system includes an ARM core module, a DSP core module, an AXI bus interconnect module, and a shared memory module, wherein... The shared memory module, which is mounted on the AXI bus, is used to store preset bit ticket variables and supports atomic operation protocols of ARM architecture atomic operation units and DSP architecture atomic operation units. The ARM core module integrates an ARM architecture atomic operation unit, a first CAS logic processing unit, and a first memory barrier control unit. It is used to complete initialization through the ARM architecture atomic operation unit when the system starts up, independently initiate lock requests through the ARM architecture atomic operation unit and the first CAS logic processing unit, detect in real time whether the lock acquisition conditions are met based on the ARM architecture atomic operation unit, access shared resources based on the first memory barrier control unit when the lock acquisition conditions are met, and independently release the lock through the ARM architecture atomic operation unit after the shared resource access is completed. The DSP core module integrates a DSP architecture atomic operation unit, a second CAS logic processing unit, and a second memory barrier control unit. It is used to initialize the system through the DSP architecture atomic operation unit, independently initiate lock requests through the DSP architecture atomic operation unit and the second CAS logic processing unit, detect whether the lock acquisition conditions are met in real time based on the DSP architecture atomic operation unit, access the shared resources based on the second memory barrier control unit when the lock acquisition conditions are met, and independently release the lock through the DSP architecture atomic operation unit after the shared resource access is completed. The AXI bus interconnect module has a built-in bus arbitration unit that supports atomic transaction transmission and enables interconnection between dual-core and shared memory modules.

2. The system according to claim 1, characterized in that, In the ARM core module, the initialization achieved through the ARM architecture atomic operation unit includes the following steps: Divide the ticket variable currently loaded from the shared memory module into a high-order ticket stub and a low-order ticket number, and set both the high-order ticket stub and the low-order ticket number to 0. Initialize the atomic operation enable flag of the dual cores to be valid; Configure the atomic access timing parameters of the AXI bus. During the initialization process, the initialization core inserts two ARM write memory barrier instructions: the first ensures that the ticket variable is loaded, and the second ensures that the initialization state is synchronized to the shared memory module, so that the DSP core can accurately read the initial state through the AXI bus.

3. The system according to claim 1, characterized in that, In the ARM core module, the step of independently initiating a lock request through the ARM architecture atomic operation unit and the first CAS logic processing unit includes the following steps: After the ARM core initiates a lock request, the ARM architecture atomic operation unit is used to execute the ARM load instruction to load the ticket variable from the shared memory module; The high-order ticket stub value of the ticket variable is extracted using the first CAS logic processing unit, and after being incremented by 1, the first updated ticket variable is determined. The first updated ticket variable includes the updated ticket stub and the initial ticket number. The first updated ticket variable is written back to the shared memory module via the ARM write-back instruction. If the write-back is successful, the ticket stub acquisition is completed. If the write-back fails, the load-update-write-back link is re-executed. After obtaining the ticket stub, it enters a spin wait state, and repeatedly reads the ticket number of the ticket variable in the shared memory module through the ARM load instruction, and determines whether the ticket stub it holds is equal to the read ticket number.

4. The system according to claim 1, characterized in that, In the ARM core module, the ARM architecture-based atomic operation unit detects in real time whether the lock acquisition condition is met. If the lock acquisition condition is met, the shared resource is accessed based on the first memory barrier control unit, including the following steps: When the ARM architecture atomic operation unit detects that the ticket stub it holds is equal to the ticket number it reads, it uses the first memory barrier control unit to insert an ARM read memory barrier instruction to prevent subsequent shared resource read operations from being reordered before lock acquisition, ensuring that the latest shared resource data is read and the shared resource is accessed. During the access process, other cores are prohibited from preempting the lock.

5. The system according to claim 1, characterized in that, In the ARM core module, the process of independently releasing the lock through the ARM architecture atomic operation unit includes the following steps: After completing the access to the shared resources, the first memory barrier control unit inserts an ARM write memory barrier instruction to ensure that all write operations to the shared resources have been refreshed to the shared memory module. The ticket variable is loaded using the ARM architecture atomic operation unit via the ARM load instruction, the low-order ticket number is extracted and incremented by 1, and the second updated ticket variable is determined. The second updated ticket variable is written back to the shared memory module via the ARM write-back instruction. If the write-back is successful, the lock is released, allowing the next core holding the ticket corresponding to the second updated ticket variable to detect that the ticket it holds is equal to the ticket number it read, thus triggering the lock acquisition process of the next core.

6. The system according to claim 1, characterized in that, In the DSP core module, the initialization is completed through the atomic operation unit of the DSP architecture, including the following steps: Divide the ticket variable currently loaded from the shared memory module into a high-order ticket stub and a low-order ticket number, and set both the high-order ticket stub and the low-order ticket number to 0. Initialize the atomic operation enable flag of the dual cores to be valid; Configure the atomic access timing parameters of the AXI bus. During the initialization process, the initialization core inserts two DSP write memory barrier instructions: the first ensures that the ticket variable is loaded, and the second ensures that the initialization state is synchronized to the shared memory module, so that the ARM core can accurately read the initial state through the AXI bus.

7. The system according to claim 1, characterized in that, In the DSP core module, the step of independently initiating a lock request through the DSP architecture atomic operation unit and the second CAS logic processing unit includes the following steps: After the DSP core initiates a lock request, the DSP architecture atomic operation unit executes the DSP load instruction to load the ticket variable from the shared memory module; The high-order ticket stub value of the ticket variable is extracted using the second CAS logic processing unit, and after being incremented by 1, the third updated ticket variable is determined. The third updated ticket variable includes the updated ticket stub and the initial ticket number. The third updated ticket variable is written back to the shared memory module via the DSP write-back instruction. If the write-back is successful, the ticket stub acquisition is completed. If the write-back fails, the load-update-write-back link is re-executed. After obtaining the ticket stub, it enters a spin-wait state, continuously reading the ticket number from the ticket variable in the shared memory module through the loading instruction, and determining whether the ticket stub it holds is equal to the read ticket number.

8. The system according to claim 1, characterized in that, In the DSP core module, the atomic operation unit based on the DSP architecture detects in real time whether the lock acquisition condition is met. If the lock acquisition condition is met, the shared resource is accessed based on the second memory barrier control unit, including the following steps: When the atomic operation unit of the DSP architecture detects that the ticket stub it holds is equal to the ticket number it reads, it uses the second memory barrier control unit to insert a DSP read memory barrier instruction to prevent subsequent shared resource read operations from being reordered before lock acquisition, ensuring that the latest shared resource data is read and the shared resource is accessed. During the access process, other cores are prohibited from preempting the lock.

9. The system according to claim 1, characterized in that, In the DSP core module, the process of independently releasing the lock through atomic operation units of the DSP architecture includes the following steps: After completing the access to the shared resources, the second memory barrier control unit inserts a DSP write memory barrier instruction to ensure that all write operations to the shared resources have been refreshed to the shared memory module. Using the atomic operation unit of the DSP architecture, the ticket variable is loaded through the DSP loading instruction, the low-order ticket number is extracted and incremented by 1, and the ticket variable after the fourth update is determined. The fourth updated ticket variable is written back to the shared memory module via the DSP write-back instruction. If the write-back is successful, the lock is released, allowing the next core holding the ticket corresponding to the fourth updated ticket variable to detect that the ticket it holds is equal to the read ticket number, thus triggering the lock acquisition process of the next core.

10. A method for implementing heterogeneous nuclear spinlock based on any one of the heterogeneous nuclear spinlock implementation systems according to claims 1 to 9, characterized in that, include: Upon system startup, initialization is completed via ARM architecture atomic operation units or DSP architecture atomic operation units. The ARM architecture atomic operation unit and the first CAS logic processing unit of the ARM core module independently initiate a lock request. The ARM architecture atomic operation unit detects in real time whether the lock acquisition conditions are met. If the lock acquisition conditions are met, the shared resource is accessed based on the first memory barrier control unit. After the shared resource access is completed, the lock is released independently through the ARM architecture atomic operation unit. Lock requests are initiated independently by the DSP architecture atomic operation unit and the second CAS logic processing unit of the DSP core module. The DSP architecture atomic operation unit detects in real time whether the lock acquisition conditions are met. If the lock acquisition conditions are met, the shared resource is accessed based on the second memory barrier control unit. After the shared resource access is completed, the lock is released independently by the DSP architecture atomic operation unit.

Images