A multi-core inter-processor lock-free memory allocation method, device and electronic equipment

Abstract

The application discloses a memory allocation method without locking among multiple cores, comprising the following steps: dividing the memory into multiple local memory pools according to the number of CPU cores, wherein the number of the local memory pools is the same as the number of the CPU cores, and each local memory pool corresponds to a different CPU core, and each CPU core does not need to be locked when applying for memory resources in the multiple local memory pools; if the required memory resources of a second CPU core are less than the memory resources in a second local memory pool, the second CPU core applies for the memory resources from the second local memory pool; otherwise, the second CPU core continues to execute; if the required memory resources of the second CPU core are greater than the memory resources in the second local memory pool corresponding to the second CPU core, the second CPU core applies for and uses the memory resources from a first local memory pool corresponding to a first CPU core through multiple shared buffers. The application further discloses corresponding devices, electronic equipment and computer readable storage media, wherein in most scenarios, each CPU core fully uses the memory resources, and the performance is optimal; when cross-core application is required, the memory allocation is realized through the shared buffer mode without locking.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a lock-free memory allocation method, apparatus and electronic device for multi-core processors. Background Technology

[0002] The rapid advancements in computer technology have brought new problems and challenges to dynamic memory allocation algorithms. In the era of single-core CPUs, the main traditional problems that memory allocation algorithms needed to solve included internal fragmentation, external fragmentation, data alignment, and locality of reference. However, increasing CPU clock speeds has reached a bottleneck. Limited by manufacturing processes and costs, it is becoming increasingly difficult to improve processor performance through traditional methods. Therefore, CPUs are gradually moving towards multi-core architectures. In high-speed real-time systems, memory management plays a crucial role. Since memory allocation during program execution is handled by dynamic memory allocation algorithms, dynamic memory allocation is particularly important in memory management. High-speed real-time systems often require frequent memory allocation and deallocation. If memory is requested from the operating system every time, it would require mapping virtual addresses to physical addresses each time, leading to efficiency issues and also negatively impacting system stability.

[0003] Currently, most mainstream PCIe SSDs employ a multi-core architecture. However, since PCIe's transfer rate far exceeds SATA's bandwidth, firmware latency must be reduced to fully utilize front-end bandwidth. The introduction of a multi-core architecture distributes firmware processes across multiple CPU cores for simultaneous execution, reducing CPU time overhead and improving performance. However, this increases the complexity of firmware development. For example, in DRAM-less firmware development, limited SRAM space needs to be shared across multiple cores. How can we ensure each CPU has sufficient resources? How can we guarantee atomic access to shared resources? These are challenging problems that need to be solved in firmware development.

[0004] Existing technologies for dynamic allocation algorithms face challenges including memory fragmentation and issues with the strategies and mechanisms used by various memory allocators. For example, the commonly used memory allocator dlmalloc employs a best-fit algorithm to allocate memory and reduces fragmentation by merging adjacent memory blocks. It uses doubly linked lists to manage small memory blocks, enabling tree-structured management of large memory blocks, and was once considered the most efficient and memory-utilizing memory allocation algorithm. Current mainstream solutions use locks to ensure each CPU has sufficient resources (including linear address to physical address translation and paging operations). The dlmalloc algorithm uses a single lock for protection; however, it doesn't consider allocation issues in multi-threaded environments. Furthermore, existing technologies also use the classic Buddy algorithm for memory allocation, commonly used in the Linux kernel and also known as the buddy system. However, this algorithm suffers from the external fragmentation problem: when two memory blocks are adjacent but not buddy blocks, the Buddy algorithm cannot connect them for allocation. Moreover, when dealing with short-lived memory allocation, the constant splitting and merging of memory blocks incurs significant overhead, reducing operational efficiency. Even if segment tree algorithms are used to improve the fragmentation problem and delayed merge algorithms are used to optimize the efficiency issues caused by frequent memory block splitting and merging, mutual exclusion access is still necessary in high-concurrency environments, which reduces efficiency.

[0005] Invented in 2004, Michael's allocator is scalable and uses a lock-free dynamic memory allocation method. To achieve lock-free operation, the algorithm breaks down the memory allocation function malloc and the memory deallocation function free into several atomic steps, allowing the current thread to call the memory allocation function regardless of the state of other threads. However, the algorithm still cannot achieve stable dynamic memory allocation, making it impossible to ensure that each CPU has sufficient resources to use and that atomic access to shared resources is guaranteed when the limited SRAM space needs to be shared among multiple cores in dramless firmware development. Summary of the Invention

[0006] The purpose of this invention is to provide a highly efficient, stable, thread-safe, lock-free inter-core memory allocation method that allocates memory to a memory pool. This method not only ensures that each CPU core fully utilizes memory resources but also achieves a lock-free effect during memory allocation, which is beneficial for further performance improvement.

[0007] This invention provides a lock-free memory allocation method for multi-core systems, comprising:

[0008] Step 1: Divide the memory into multiple local memory pools that correspond one-to-one with the number of CPU cores, based on the number of CPU cores. Each local memory pool corresponds to a different CPU core. When each CPU core requests memory resources from the multiple local memory pools, no locking is required.

[0009] Step 2: If the memory resources required by the second CPU core are less than the memory resources in its corresponding second local memory pool, then the second CPU core requests memory resources from the second local memory pool; otherwise, proceed to step 3.

[0010] Step 3: If the memory resources required by the second CPU core are greater than the memory resources in its corresponding second local memory pool, the second CPU core requests and uses memory resources from the first local memory pool corresponding to the first CPU core through multiple shared buffers.

[0011] Furthermore, in step 1, the specific division of the local memory pool is based on the business scope of memory usage, and the local memory pool can be dynamically adjusted in real time.

[0012] Further, step 3 includes:

[0013] Step 31: Write the memory resources in the first local memory pool into the first shared buffer;

[0014] Step 32: The second CPU core obtains memory resources from the first local memory pool in the first shared buffer as the second temporary memory resource;

[0015] Step 33: Based on the end signal sent in the message queue after the second temporary memory resource has been used up, the second CPU core writes the second temporary memory resource into the second shared buffer.

[0016] Step 34: After the first CPU core obtains the second temporary memory resource from the second shared buffer, it places the second temporary memory resource back into the first local memory pool.

[0017] Furthermore, steps 31 and 33 are implemented by writing to the cursor wptr; and steps 32 and 34 are implemented by reading from the cursor rptr.

[0018] Furthermore, each local memory pool contains multiple pages, and each page has only two states: allocated and idle. A bitmap is used to mark the state of each page, with each bit in the bitmap corresponding to a page. If a page is allocated, the corresponding bit is 0; if a page is idle, the corresponding bit is 1. Then, the bitmap is combined with atomic operations to achieve the lock-free memory allocation.

[0019] Furthermore, the lock-free memory allocation method between multiple cores also includes a double-judgment mechanism, that is, after the memory request thread sets the search bitmap to 0, it checks again whether the corresponding slice in the secondary bitmap is 0. If it is not 0, the corresponding slice in the search bitmap is set to 1 again.

[0020] Furthermore, after obtaining the second temporary memory resource in step 32, the second temporary memory resource and the memory resources in the first local memory pool are not immediately merged into memory blocks. Instead, they are merged gradually. The merging process is a distributed search process of the first-level bitmap. The number of consecutive 1s is searched from front to back in the bitmap through bit operations. Then, these free pages are merged into a large memory block and the corresponding second-level bitmap and search bitmap are set. Whenever a free block is merged, it is checked whether the merging time limit has been exceeded. If it has, the position of the first-level bitmap is recorded so that the next merging operation can continue. If no memory block can meet the demand after each merging timeout, a memory block is requested from the operating system to meet the demand.

[0021] A second aspect of the present invention provides a lock-free memory allocation device for multi-core systems, comprising:

[0022] The local memory pool partitioning module divides the memory into multiple local memory pools that are the same number of CPU cores and correspond one-to-one with the number of CPU cores. Each local memory pool corresponds to a different CPU core. When each CPU core requests memory resources in the multiple local memory pools, no locking is required.

[0023] In the intra-core memory allocation module, if the memory resources required by the second CPU core are less than the memory resources in its corresponding second local memory pool, then the second CPU core requests memory resources from the second local memory pool; otherwise, it performs inter-core memory allocation.

[0024] The multi-core memory allocation module requires more memory resources than the corresponding second local memory pool of the second CPU core. The second CPU core requests and uses memory resources from the first local memory pool corresponding to the first CPU core through multiple shared buffers.

[0025] A third aspect of the present invention provides an electronic device including a processor and a memory, the memory storing a plurality of instructions, the processor being configured to read the instructions and execute the method as described in the first aspect.

[0026] A fourth aspect of the present invention provides a computer-readable storage medium storing a plurality of instructions which can be read by a processor and executed as described in the first aspect.

[0027] This invention provides a lock-free memory allocation method, apparatus, and electronic device for multi-core processors, which have the following advantages:

[0028] (1) It can be applied to different business models, and it can lock-free memory resource allocation, thereby maximizing multi-core performance and reducing maximum latency and fluctuation.

[0029] (2) This embodiment operates in a high-concurrency environment. The memory allocation efficiency of this lock-free inter-core memory allocation method is higher than that of ordinary locked memory allocation methods, and this efficiency improvement becomes more significant as the concurrency increases. In a single-threaded environment, the allocation efficiency is improved by approximately 29% when performing continuous random-size memory allocation; and by 33% when performing continuous fixed-size memory allocation. When performing continuous approximate-size memory allocation, a progressive re-merging algorithm is used, which improves memory allocation efficiency by delaying the merging of memory blocks. In a concurrent environment with a single-producer, multi-consumer model, when performing continuous random-size memory allocation, the efficiency of the traditional algorithm continuously decreases as the number of consumer threads increases, and the higher the concurrency, the faster the efficiency decreases. This is because as the number of threads increases or decreases, the problems of using locks to achieve concurrency are exposed, and frequent lock contention severely reduces the algorithm efficiency.

[0030] (3) This method uses a continuous data structure, which also results in a higher cache hit rate. In a special operating environment, namely a multi-threaded environment with continuous fixed memory allocation, this invention is more suitable for high-speed real-time systems and high-concurrency environments in terms of stability and allocation efficiency. Attached Figure Description

[0031] Figure 1 This is a flowchart of a preferred embodiment of the lock-free memory allocation method between multiple cores provided by the present invention.

[0032] Figure 2 This is a schematic diagram of a preferred embodiment of the lock-free memory allocation device for multi-core processors provided by the present invention.

[0033] Figure 3 This is a schematic diagram of the structure of an embodiment of the electronic device provided by the present invention. Detailed Implementation

[0034] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0035] The lock-free memory allocation method between multiple cores in this embodiment includes:

[0036] Step 1: Divide the memory into multiple local memory pools that correspond one-to-one with the number of CPU cores, based on the number of CPU cores. Each local memory pool corresponds to a different CPU core. No locking is required when a CPU core requests memory resources from multiple local memory pools.

[0037] Step 2: If the memory resources required by the second CPU core are less than the memory resources in its corresponding second local memory pool, then the second CPU core requests memory resources from the second local memory pool; otherwise, proceed to step 3.

[0038] Step 3: The memory resources required by the second CPU core are greater than the memory resources in its corresponding second local memory pool. The second CPU core requests and uses memory resources from the first local memory pool corresponding to the first CPU core through multiple shared buffers.

[0039] In a preferred embodiment, step 1 involves dividing the local memory pool according to the scope of business use of the memory.

[0040] Step 3 includes:

[0041] Step 31: Write the memory resources in the first local memory pool into the first shared buffer;

[0042] Step 32: The second CPU core obtains memory resources from the first local memory pool in the first shared buffer as the second temporary memory resources;

[0043] Step 33: Based on the end signal sent in the message queue after the second temporary memory resource has been used up, the second CPU core writes the second temporary memory resource into the second shared buffer.

[0044] Step 34: After the first CPU core obtains the second temporary memory resource from the second shared buffer, it places the second temporary memory resource back into the first local memory pool.

[0045] Steps 31 and 33 are implemented by writing to the cursor wptr. Steps 32 and 34 are implemented by reading from the cursor rptr.

[0046] The cursor's role is to iterate through and output the result set. Writing and reading cursors can be implemented using a circular buffer, for example, as follows:

[0047] For example, the initial state is rptr = wptr = 0; where the shared region is buf[size].

[0048] When one of the CPUs writes resources to the shared region:

[0049] if (wptr + 1 != rptr)

[0050] buf[wptr++] = resource;

[0051] When another CPU reads resources from a shared area:

[0052] if(rptr <wptr)

[0053] returnbuf[rptr++]

[0054] When rptr and wptr reach the size of the shared region, they start from 0 again.

[0055] wptr = wptr%size;

[0056] Each local memory pool contains multiple pages, each with only two states: allocated and free. A bitmap is used to mark the state of each page, with each bit in the bitmap corresponding to a page. If a page is allocated, the corresponding bit is 0; if a page is free, the corresponding bit is 1. The bitmap is then combined with atomic operations to achieve lock-free memory allocation. The lock-free memory allocation method includes a first-level bitmap, where each bit corresponds to the current page's usage state. Multiple free tables are maintained, each consisting of a search bitmap and a second-level bitmap. The second-level bitmap identifies free memory blocks. To speed up the search for the first free block, a search bitmap is introduced, where each bit corresponds to a bitmap slice in the second-level bitmap. Each bitmap is an integer array, and each integer text within it is called a bitmap slice. If a bitmap slice is 0, the corresponding bit in the search bitmap is 0; otherwise, it is 1. In this embodiment, when there are 2... k When there is a free memory block of a certain size, the bit corresponding to the first page of the free memory block in the second-level bitmap of the k-th free table is marked as 1.

[0057] In high-concurrency programs, critical sections are a major performance bottleneck. When using locks as synchronization, only one thread can be in the critical section at a time. Lock-free algorithms, however, allow multiple threads to run without blocking each other. Therefore, with atomic operations, multiple threads can enter the critical section simultaneously, and ordinary instructions can be executed concurrently. Furthermore, the use of contiguous data structures reduces the probability of cache misses, and the performance of atomic operations is approximately twice that of locks. Therefore, the overall overhead of atomic operations is less than that of using locks as synchronization. In addition, this lock-free memory allocation method can quickly locate secondary bitmap slices by searching the bitmap when the total memory is not too large, thus allocating and releasing memory blocks with low time complexity. When the total memory is large, it divides the total memory into multiple smaller local memory blocks, and then calls the memory allocation method on each smaller memory block.

[0058] An atomic operation is atomic, but multiple atomic operations are not necessarily atomic. Therefore, although setting the search bitmap and setting the secondary bitmap are both atomic operations, their combination is not necessarily concurrency-safe. This problem can be solved by locking, but it suffers from the common drawbacks of locking solutions. Therefore, the lock-free memory allocation method between multi-core processors in this embodiment also includes a double-check mechanism: after the memory allocation thread sets the search bitmap to 0, it checks again whether the corresponding slice in the secondary bitmap is 0. If it is not 0, the corresponding slice in the search bitmap is reset to 1.

[0059] In a preferred embodiment, after obtaining the second temporary memory resource in step 32, the second temporary memory resource and the memory resources in the first local memory pool are not immediately merged into memory blocks. Instead, a gradual merging process is performed. This merging process is a distributed search process of the first-level bitmap. The memory allocator searches for the number of consecutive 1s in the bitmap from front to back using bit operations, and then merges these free pages into memory blocks of the largest possible size and sets the corresponding second-level bitmap and search bitmap. Whenever a free block is merged, it is checked whether the merging time limit has been exceeded. If it has, the position of the first-level bitmap at this stage is recorded so that the next merging operation can continue. If no memory block that can meet the demand is found after each merging timeout, a memory block is requested from the operating system to meet the demand. Through gradual merging, this method reduces the load caused by frequent memory allocation and release and constant splitting and merging, reduces external fragmentation, and can merge any adjacent pages compared to traditional memory allocation methods.

[0060] The relevant algorithms in this embodiment include:

[0061] I. Memory Block Allocation Algorithm

[0062] The core of the allocation is a bitmap search kernel setting function. This function obtains the physical block to be allocated. The allocation algorithm first calculates the minimum number of pages required to satisfy the memory request and finds the first suitable interval idx. Then, it uses the assembly instruction bsfl to find the first 1 bit of the search bitmap of interval idx, stores its index in the variable firstBit, and searches the firstBit bitmap slice of the secondary bitmap. Based on the search results, it finds the starting address of the memory block to be allocated. Finally, the excess memory is divided into other intervals and the corresponding bitmaps are set. The process is described as follows:

[0063] Input: The size of the requested memory (memSize in bytes)

[0064] Output: The starting address of the allocated memory block

[0065] The first step is to calculate the minimum number of pages required to meet the demand based on the requested memory size memSize.

[0066] The second step is to start searching from the smallest memory block range that meets the requirements, and find the first range where the search bitmap is not 0;

[0067] The third step is to find the first 1-bit in the search bitmap and record its index idx.

[0068] The fourth step is to search the idx-th bitmap slice in the secondary bitmap, find the first 1 bit, and record the bit index in firstBit;

[0069] Fifth step: Create 32+firstBit pages in the local memory pool;

[0070] The sixth step is to divide the memory block starting from this page into two parts: the first part is the minimum memory block that meets the requirements, and the second part is the remaining memory block.

[0071] The seventh step is to assign the remaining memory blocks to the corresponding ranges, i.e., to set up the secondary bitmap and the search bitmap;

[0072] Step 8: Set up a first-level bitmap based on the starting position and size of the allocated memory block, and return the starting address of the memory block.

[0073] II. Memory Block Release Algorithm Design

[0074] The core of the memory block release algorithm lies in address calculation and bitmap search and setup. Based on the memory block's starting address, the memory pool's starting address, and the page size, the algorithm calculates the starting address of the memory block within the memory pool, and sets up the first-level, second-level, and search bitmaps accordingly. Specific steps include:

[0075] Input: The starting address of the memory block to be freed (void*pData)

[0076] Output: None

[0077] The first step is to calculate the offset of the memory block starting address pData relative to the memory pool starting address;

[0078] The second step is to calculate the starting page index of the memory block, pageIdx = offset / pageSize, based on the offset and page size.

[0079] The third step is to set the page descriptor of the starting page of the memory block. The page descriptor includes information such as the usage of the memory block starting from that page and the size of the memory block.

[0080] The fourth step is to find the corresponding range based on the size of the memory block to be released, and then search for the corresponding bitmap slice in the secondary bitmap by starting the page and searching for pageIdx, and set the corresponding bits.

[0081] Step 5: If the value before the corresponding bitmap slice is 0, then it is also necessary to set the corresponding bit in the search bitmap for this slice;

[0082] Step 6: Set the first-level bitmap.

[0083] III. Progressive Recombination Algorithm Design

[0084] The progressive recombination algorithm first calculates which page the current recombination has reached and saves the progress in remergeIdx, finds the first 1 bit and the first 0 bit starting from the remergeIdx bit of the first-level bitmap, calculates the difference between the two to obtain the size of the continuous free pages, divides them into corresponding intervals according to the free size and sets the bitmaps of the corresponding intervals. If the total time used by the recombination algorithm exceeds the maximum limit time after this merge, then jump out of the recombination algorithm. The specific steps are as follows:

[0085] Input: None

[0086] Output: None

[0087] Step 1: Obtain the system time startTime as the starting moment of this recombination;

[0088] Step 2: Calculate the current recombination progress, that is, which bit of the first-level bitmap the previous recombination operation reached, and record the index value of the bit in remergeIdx;

[0089] Step 3: In the first-level bitmap, continuously search for a 1 bit backward from the remergeIdx-th bit;

[0090] Step 4: Obtain the size of the memory block according to the number of continuous 1 bits, divide the memory block into one or more intervals, and preferentially divide it into large memory block intervals;

[0091] Step 5: Obtain the system time endTime;

[0092] Step 6: Calculate the duration of this recombination, endTime - startTime. If it exceeds the maximum time limit TIME_LIMIT, then immediately end the recombination;

[0093] Step 7: If not timed out, then go back to Step 2. [[ID=3??]]

[0094] Example 1

[0095] Reference Figure 1 It seems there is a small error in your original text where the tag in line might be incorrect as it shows as [ID=3??]. I've translated it as best as possible with the provided content.As shown, this embodiment provides a lock-free memory allocation method (algorithm) for multi-core systems, based on local resource pools and shared buffers. Embodiment 1 uses a dual-CPU core architecture (hereinafter referred to as Core) as an example to illustrate the implementation details of the algorithm. It demonstrates the process of Core 2 requesting memory resources; the process for Core 1 is similar or identical, except that memory resources are swapped or replaced. During system startup, memory is divided into two local memory pools based on the business needs of the two Cores. These two local memory pools belong to different CPU cores; each CPU core does not need to lock when requesting memory resources in its local memory pool. During memory allocation, it is necessary to ensure that the Core allocation can guarantee the operation of basic business processes. For example, if 80% of the scenarios on core 1 require 8 resources, and extreme cases require 16, then only 8 resources need to be allocated.

[0096] The specific process includes:

[0097] Step 1: In most scenarios (i.e., when the corresponding memory resources are sufficient), Core 2 requests memory resources from local memory pool 2;

[0098] Step 2: When it is necessary to request resources from local memory pool 1, write the resources in local memory pool 1 to the shared buffer Ring Buffer 0 through the write cursor wptr;

[0099] Step 3: Core 2 reads memory resources from the shared buffer Ring Buffer 0 using the read cursor rptr as temporary memory resources;

[0100] Step 4: After the temporary memory resources are used up, Core 2 writes the memory resources belonging to local resource pool 1 to the shared buffer Ring Buffer 1 through the write cursor wptr;

[0101] Step 5: After Core 1 reads the temporary memory resource from Ring Buffer 1 using the read cursor rptr, it returns the temporary memory resource to local memory pool 1.

[0102] The entire process described above does not require adding locks for mutual exclusion; if the local resource pool is not properly divided, the two local resource pools can be dynamically adjusted.

[0103] Example 2

[0104] refer to Figure 2 This invention provides a lock-free memory allocation device for multi-core systems, comprising:

[0105] The local memory pool partitioning module 201 divides the memory into multiple local memory pools that are the same number of CPU cores and correspond one-to-one with the number of CPU cores. Each local memory pool corresponds to a different CPU core. When a CPU core requests memory resources in multiple local memory pools, no locking is required.

[0106] In the core memory allocation module 202, if the memory resources required by the second CPU core are less than the memory resources in its corresponding second local memory pool, the second CPU core requests memory resources from the second local memory pool; otherwise, it performs inter-core memory allocation.

[0107] The multi-core memory allocation module 203 requires more memory resources than the corresponding second local memory pool of the second CPU core. The second CPU core requests and uses memory resources from the first local memory pool corresponding to the first CPU core through multiple shared buffers.

[0108] This device can be implemented using the lock-free memory allocation method between multiple cores provided in Embodiment 1 above. For the specific implementation method, please refer to the description in Embodiment 1, which will not be repeated here.

[0109] The present invention also provides a memory that stores a plurality of instructions for implementing the method as described in Embodiment 1.

[0110] like Figure 3 As shown, the present invention also provides an electronic device, including a processor 301 and a memory 302 connected to the processor 301. The memory 302 stores a plurality of instructions, which can be loaded and executed by the processor to enable the processor to perform the method as described in Embodiment 1.

[0111] With this lock-free memory allocation method (algorithm) and device for multi-core CPUs, in most scenarios, CPU cores request resources from the local storage pool, ensuring optimal performance; when cross-core requests are required, they can also be achieved through a lock-free shared buffer.

[0112] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention. Clearly, those skilled in the art can make various alterations and modifications to the invention without departing from its spirit and scope. Thus, if these modifications and modifications of the invention fall within the scope of the claims and their equivalents, the invention is also intended to include these modifications and modifications.

Claims

1. A lock-free memory allocation method for multi-core processors, characterized in that... include: Step 1: Divide the memory into multiple local memory pools that correspond one-to-one with the number of CPU cores, based on the number of CPU cores. Each local memory pool corresponds to a different CPU core. When each CPU core requests memory resources from the multiple local memory pools, no locking is required. Step 2: If the memory resources required by the second CPU core are less than the memory resources in its corresponding second local memory pool, then the second CPU core requests memory resources from the second local memory pool. Otherwise, proceed to step 3; Step 3: If the memory resources required by the second CPU core are greater than the memory resources in its corresponding second local memory pool, the second CPU core requests and uses memory resources from the first local memory pool corresponding to the first CPU core through multiple shared buffers, including: Step 31: Write the memory resources in the first local memory pool into the first shared buffer; Step 32: The second CPU core obtains memory resources from the first local memory pool in the first shared buffer as the second temporary memory resource; Step 33: Based on the end signal sent in the message queue after the second temporary memory resource has been used up, the second CPU core writes the second temporary memory resource into the second shared buffer. Step 34: After the first CPU core obtains the second temporary memory resource from the second shared buffer, it places the second temporary memory resource back into the first local memory pool; After obtaining the second temporary memory resource in step 32, the second temporary memory resource and the memory resources in the first local memory pool are not immediately merged into memory blocks. Instead, they are gradually merged. The merging process is a distributed search process of the first-level bitmap. Bitwise operations are used to search for the number of consecutive 1s in the bitmap from front to back. Then, these free pages are merged into a large memory block and the corresponding second-level bitmap and search bitmap are set. Whenever a free block is merged, it is checked whether the merging time limit has been exceeded. If it has, the position of the first-level bitmap is recorded so that the next merging operation can continue. If no memory block can meet the demand after each merging timeout, a memory block is requested from the operating system to meet the demand. Each local memory pool contains multiple pages. Each page has only two states: allocated and free. A bitmap is used to mark the state of each page. Each bit in the bitmap corresponds to a page. If a page is allocated, the corresponding bit is 0. If a page is free, the corresponding bit is 1. Then, the bitmap is combined with atomic operations to achieve the lock-free memory allocation. The lock-free memory allocation method between multiple cores also includes a double-judgment mechanism, that is, after the memory request thread sets the search bitmap to 0, it checks again whether the corresponding slice in the secondary bitmap is 0. If it is not 0, the corresponding slice in the search bitmap is set to 1 again.

2. The lock-free memory allocation method between multiple cores according to claim 1, characterized in that: The specific division of the local memory pool in step 1 is based on the business scope of memory usage, and the local memory pool can be dynamically adjusted in real time.

3. The lock-free memory allocation method between multiple cores according to claim 1, characterized in that: Steps 31 and 33 are implemented by writing to the cursor wptr; steps 32 and 34 are implemented by reading from the cursor rptr.

4. A lock-free memory allocation device for multi-core systems, characterized in that, For performing the method according to any one of claims 1-3, comprising: The local memory pool partitioning module divides the memory into multiple local memory pools that are the same number of CPU cores and correspond one-to-one with the number of CPU cores. Each local memory pool corresponds to a different CPU core. When each CPU core requests memory resources in the multiple local memory pools, no locking is required. In the intra-core memory allocation module, if the memory resources required by the second CPU core are less than the memory resources in its corresponding second local memory pool, then the second CPU core requests memory resources from the second local memory pool; otherwise, it performs inter-core memory allocation. The multi-core memory allocation module requires more memory resources than the corresponding second local memory pool of the second CPU core. The second CPU core requests and uses memory resources from the first local memory pool corresponding to the first CPU core through multiple shared buffers.

5. An electronic device, characterized in that, It includes a processor and a memory, the memory storing multiple instructions, and the processor being used to read the instructions and execute the method as described in any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions, which can be read by a processor and executed as described in any one of claims 1 to 3.

Images