Optimistic batch processing based lock-free data structure memory reclamation method

Abstract

The application discloses a memory recycling method of a lock-free data structure based on optimistic batch processing, and mainly solves the problem that the existing memory recycling scheme cannot guarantee lock-free progress while ensuring efficient operation of a system by using a multi-core processor. The implementation scheme comprises the following steps: a global cycle counter is used to record a cycle in which a thread is located, and the life cycle of each memory object is recorded to jointly determine whether the memory object can be safely recycled; an object pool group comprising a preparation pool, a temporary storage pool and a processing pool is constructed; a work thread performs an insertion or deletion operation, and all memory objects in the current temporary storage pool are recycled in batches to be used for next allocation; and other concurrent threads directly read the memory objects in the data structure, and the safety of the recycling operation is ensured by an optimistic batch processing alarm. The application can reduce the performance overhead of the data structure and improve the use efficiency of the processor under the premise of guaranteeing lock-free progress, and can be used in a multi-core machine integrated with multiple processing units to ensure high-performance operation.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and specifically relates to a memory reclamation method for lock-free data structures, which can be used in multi-core machines with integrated processing units to ensure the high-performance operation of their software systems. Background Technology

[0002] In traditional multithreaded programming, locks are often used to protect access to shared data structures to avoid data races and inconsistencies caused by concurrent access. However, using locks can introduce significant performance overhead and complexity, and can lead to deadlock problems.

[0003] With the continuous development of computer hardware technology, multi-core processors have made significant progress. Compared to traditional single-core processors, multi-core processors integrate multiple independent processing cores on the same chip, enabling computer systems to execute multiple threads or processes simultaneously, significantly improving parallel processing capabilities. However, in high-concurrency scenarios, data structures protected by locks cause multiple threads to block and wait to acquire locks, which inherently contradicts concurrency. Therefore, data structures protected by locks cannot meet the urgent needs of today's high-performance multi-core machines.

[0004] Lock-free data structures are data structures used in multithreaded environments. Their design and implementation do not rely on traditional locks, such as mutexes or read-write locks, to implement synchronization mechanisms for concurrent access. Lock-free data structures allow multiple threads to simultaneously read and modify the data structure without explicitly using locks to protect shared resources. The definition of lock-free data structures includes the following key characteristics:

[0005] Concurrent operations: Lock-free data structures allow multiple threads to read and modify data structures simultaneously, fully utilizing the parallelism of multi-core processors.

[0006] Lock-free operations: Operations on lock-free data structures will not be blocked or suspended, and will not cause mutual exclusion or competition between threads. Instead, concurrency safety is achieved through algorithm design.

[0007] No waiting: In a multi-threaded environment, lock-free data structures ensure that even if some threads fail or are delayed, it will not affect the normal execution of other threads, thus achieving no waiting, meaning that each thread can complete its operation within a finite amount of time.

[0008] Atomicity: Operations on lock-free data structures are typically atomic, meaning they either succeed completely or fail completely, with no intermediate state.

[0009] The design and implementation of lock-free data structures typically require underlying hardware support, such as atomic operations and CAS (Compare-and-Swap) instructions, to achieve concurrency safety.

[0010] Furthermore, when designing lock-free data structures, it is crucial to ensure the correct and safe reclamation of memory. Since multiple threads can concurrently access objects within a data structure, simultaneous read / write and reclamation operations on the same memory object may result in reads and writes to already reclaimed memory. Such errors can range from simply reading incorrect results to corrupting data, or even crashing the program and server, leading to serious security vulnerabilities. Therefore, lock-free data structures must employ a memory reclamation method to prevent conflicts between read / write operations and reclamation.

[0011] Memory reclamation methods for lock-free data structures refer to the ways in which unused memory is reclaimed and released within a lock-free data structure. These methods address the memory reclamation problem in lock-free data structures: as long as any thread still holds a reference to a memory object and may access it later, that memory object cannot be deleted. If a thread wants to "release" a memory object, it cannot directly perform a deletion operation; instead, it performs a retirement operation to store a pointer and postpones reclamation until it is safe to do so.

[0012] In applications using lock-free data structures, achieving this ideal progress guarantee requires that memory reclamation is also lock-free. Otherwise, executing threads might be blocked indefinitely while attempting allocation, thus violating the lock-free progress guarantee.

[0013] For a data structure, the data it contains is collectively referred to as the data structure's memory objects. Deleting unused memory objects from a data structure typically involves three steps: logical deletion, physical deletion, and memory reclamation. Logical deletion involves marking the memory object to be deleted. This is usually done using the last two bits of a pointer; marking indicates deletion, and if other threads detect that the memory object is marked, it means the object no longer exists. Physical deletion involves removing the memory object from a linked list or array and adding it to a list of objects to be deleted. This step waits for all potential operations on the memory object by any threads to complete. Memory reclamation removes the object from the list of objects to be deleted and returns the memory to the operating system or to the memory pool used by the user for memory allocation.

[0014] Current memory reclamation schemes can be broadly categorized into three types: pointer-based reclamation, periodic reclamation, and optimistic reclamation.

[0015] US Patent Application Publication No. US10308449 discloses a method for memory reclamation of dynamic lock-free data structures. It allocates several shared pointers called risk pointers to each thread accessing a lock-free object. A risk pointer is either null or points to a memory object that may be subsequently accessed by other threads. Risk pointers can only be written to by the thread that owns them, but other threads are allowed to read them. When reading or writing a memory object, the pointer to the memory object being read or written is saved to a globally visible risk pointer area, and the risk pointer is cleared after the read / write operation is completed. When attempting to reclaim memory, any memory objects pointed to by risk pointers will not be reclaimed temporarily.

[0016] This method requires a lock-free algorithm to ensure that no thread can access a memory object if it may have been deleted. It prevents the deletion of any object pointed to by an arbitrary risk pointer. Whenever a thread retires an object, that object is kept in the thread's local retirement list. After a certain number of retired objects have accumulated, the thread scans the risk pointers of other threads. If a retired memory object does not match any risk pointer, it can be safely released. Otherwise, releasing the object is unsafe, so it is not reclaimed until the next scan of these risk pointers. While this approach provides lock-free progress guarantees, it incurs significant performance overhead. Especially on multi-core machines with integrated multiprocessing units, this memory reclamation scheme becomes a severe performance bottleneck, preventing the machine from achieving its expected concurrent performance.

[0017] In their paper "Interval-Based Memory Reclamation" published at ACM SIGPLAN Notices 2018, Haosen Wen et al. proposed an interval-based memory reclamation scheme. This scheme deploys a periodically incrementing global cycle counter in the data structure. When a thread attempts to perform a read or write operation, it records its current global cycle as the start cycle. When attempting to reclaim memory, reclamation is only performed if the start cycle recorded for the current object is less than the start cycles of all threads. If the start cycle recorded by the current thread is greater than the start cycles of any other thread, it indicates that the memory object may be being read or written, and therefore deletion should not be performed. This type of scheme typically has good performance, but it does not provide lock-free progress guarantees because stalled threads may prevent an unlimited number of memory objects from being reclaimed. In the worst case, these objects will consume excessive memory space, causing all new allocation operations to be blocked.

[0018] In their paper "Efficient Memory Management for Lock-Free Data Structures with Optimistic Access," published in the Proceedings of the 27th ACM symposium on Parallelelismin Algorithms and Architectures, Nachshon Cohen et al. proposed an optimistic access scheme that allows reading objects that have been physically deleted and added to a temporary list awaiting reclamation. However, for write operations, the previously described risky pointer scheme is still used. After a read operation, if the read node has been deleted, the thread's reclamation warning flag indicates that other threads may have performed reclamation operations during the read, requiring the read value to be discarded and the read operation to be retried. Although this scheme provides better read performance and lock-free progress guarantees, it still faces the performance overhead of risky pointers, and the concurrency conflicts between threads during memory reclamation can severely degrade the overall performance of lock-free data structures, resulting in the system actually operating serially.

[0019] Huatai Securities Co., Ltd. disclosed a lock-free shared memory solution for concurrent read / write in multi-process scenarios in its patent application document CN109298935A. This solution employs the copy-on-write principle, supporting one-to-many reads of shared memory. When data is updated, a new unused shared memory space is allocated from the shared memory for the data to be updated, and the data is written to this memory space. Then, the data key-value relationship is modified. Once it is ensured that no thread is reading from the shared memory, the old data area is reclaimed for memory allocation for the next data addition or update. Because the key-value relationship is updated only after the data is updated, no data area is read or written simultaneously. While this method avoids the use of locks, thus providing high-performance real-time data access capabilities during high-frequency data updates, its low memory utilization efficiency and poor performance provided by copy-on-write fail to meet the performance requirements of upper-layer applications.

[0020] Guangzhou Huya Technology Co., Ltd. disclosed a lock-free shared memory processing scheme that does not require memory reclamation in its patent application document CN110287044A. This scheme configures independent memory configuration data for each service, maps shared memory files to shared memory regions using a preset memory mapping method, and obtains the return value after mapping. Subsequently, based on this return value, the starting pointer address and offset record pointer address of the corresponding shared memory region are recorded in the application memory corresponding to the data service. Since each service only needs to access its own allocated shared memory region and does not need to read the memory regions of other services, it can avoid problems such as data competition or race conditions caused by multiple processes or threads. However, this scheme does not solve the problem of memory reclamation within processes or threads and generates a large amount of memory fragmentation, which can seriously damage system performance. Summary of the Invention

[0021] The purpose of this invention is to address the shortcomings of the prior art by proposing a lock-free data structure memory reclamation method based on optimistic batch processing, so as to reduce the performance overhead of lock-free data structures and improve the utilization efficiency of multi-processing units integrated in multi-core machines while providing lock-free progress guarantees.

[0022] To achieve the above objectives, the present invention includes the following steps:

[0023] (1) Create a chained lockless data structure that includes an optimistic batch alerter, a tracker, a global cycle recorder, an allocator, and a reclaimer;

[0024] (2) Create an object pool group equal to the number of threads. Each thread's object pool group includes a preparation pool, a temporary pool, and a processing pool.

[0025] (3) Perform initialization operations on the preparation pool in each object pool group;

[0026] (4) Based on the business needs of the users of this lock-free data structure, create several worker threads. Each thread continuously performs deletion or insertion operations on the lock-free data structure. For each operation, first determine the operation that the thread is to perform:

[0027] If it is an insertion operation, then determine whether the memory object can be obtained from the corresponding object pool:

[0028] If it can be obtained, that is, the preparation pool is not empty, then jump to step (7);

[0029] If it cannot be obtained, that is, the preparation pool is empty, then proceed to step (5);

[0030] If it is a deletion operation, execute the deletion operation directly, and then determine whether the user has explicitly specified recycling or the recycling threshold has been reached:

[0031] If the user explicitly specifies recycling or the recycling threshold is reached, then proceed to step (5);

[0032] If the user does not explicitly specify and the recycling threshold has not been reached, proceed to step (7);

[0033] (5) Determine whether to perform memory reclamation based on the state of the object pool corresponding to the thread:

[0034] If the preparation pool memory corresponding to the thread is sufficient, there is no need to trigger memory reclamation.

[0035] If there are no objects available for allocation in the preparation pool corresponding to the thread, or if the number of objects in the temporary pool reaches the recycling threshold, the recycling operation of the thread is triggered, and all memory objects in the temporary pool are moved into the processing pool and step (6) is executed.

[0036] If a thread actively requests memory reclamation or reaches the reclamation threshold, a garbage collection operation is triggered, moving all memory objects in the temporary pool into the processing pool and executing step (6).

[0037] (6) Perform garbage collection on the thread object pool group:

[0038] (6a) Call the tracer to record the cycle of all threads and obtain the cycle R of the thread with the shortest cycle among all threads. low And the thread cycle with the longest duration R high That is, the range of the thread R = [R low ,R high ];

[0039] (6b) Call the optimistic batch alerter to set the reclamation flag of all threads to true, indicating that a certain thread has triggered a memory reclamation operation; when other threads read that the corresponding flag is true, they will roll back the unfinished operation and re-execute it.

[0040] (6c) Retrieve the first object added to the processing pool, based on the insertion cycle recorded at the time of insertion. The deletion cycle recorded during logical deletion Obtain its lifecycle

[0041] (6d) Determine whether the memory object can be safely reclaimed based on its lifecycle E:

[0042] If the lifetime of a memory object is empty, it can be safely reclaimed and moved directly into the preparation pool.

[0043] if That is, if the lifecycle E of a memory object has no overlap with the scope R of the thread, the memory object can be safely reclaimed and moved to the preparation pool.

[0044] Otherwise, the memory object cannot be safely reclaimed temporarily and is moved to the temporary pool for processing in the next stage;

[0045] (6e) Determine if the processing pool is empty:

[0046] If the processing pool is not empty, return (6c);

[0047] If the processing pool is empty, the garbage collection operation is complete, and step (7) is executed;

[0048] (7) Based on the insertion or deletion operation performed on the lock-free data structure, determine the subsequent operation to be performed:

[0049] If an insertion operation is performed on a lock-free data structure, the thread first obtains the memory object from the corresponding object pool, inserts the memory object into the lock-free data structure, and then returns to step (4) to wait for the next insertion or deletion operation.

[0050] If a lock-free data structure performs a deletion operation, it returns directly to step (4) to wait for the next insertion or deletion operation.

[0051] Compared with the prior art, the present invention has the following advantages:

[0052] Because this invention uses an independent object pool group for each thread to store memory objects to be reclaimed, compared to interval-based memory reclamation schemes, there is no need to consider the synchronization problem between threads during reclamation, and the blocking of one thread will not cause the reclamation operation of all other threads to be blocked, thus ensuring lock-free progress.

[0053] This invention employs an optimistic batch alerter to ensure that other threads do not read reclaimed memory. Compared to existing pointer-based memory reclamation schemes, it eliminates the need to record the objects being read by each thread, thus avoiding the severe performance bottleneck caused by synchronizing multiple worker threads in multi-processor concurrent scenarios. This allows the invention to exhibit higher performance on multi-core machines and improves the utilization efficiency of multi-processor units.

[0054] This invention employs a tracker to record the thread's lifecycle at each insertion or deletion operation. During garbage collection, it compares the lifecycle of the memory object to be reclaimed with the lifecycles of all threads. If none of the thread lifecycles overlap with the object's lifecycle, the memory object can be safely reclaimed. Compared to existing optimistic memory reclamation schemes, this comparison method efficiently determines whether a memory object is safe for reclamation. Furthermore, because this invention uses thread-local object pools, it avoids inter-thread conflicts, significantly improving the parallelism of multiple processing units, thereby maximizing system performance and the efficiency of multi-processor utilization on multi-core machines.

[0055] Compared to the existing Huatai Securities solution, this invention can be applied to a wider range of business scenarios because it supports multiple read / write concurrent business scenarios. Attached Figure Description

[0056] Figure 1 This is a flowchart illustrating the overall implementation of the present invention;

[0057] Figure 2 This is a diagram of the lock-free data structure architecture constructed in this invention;

[0058] Figure 3 This is a diagram of the thread pool group architecture constructed in this invention;

[0059] Figure 4 This is a sub-flowchart of inserting memory objects into a lock-free data structure in this invention;

[0060] Figure 5 This is a sub-flowchart of the present invention for deleting memory objects in lock-free data structures;

[0061] Figure 6 This is a flowchart of the garbage collection process in the object pool group of this invention. Detailed Implementation

[0062] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0063] Reference Figure 1 This invention provides two embodiments to illustrate its technical solution, but is not limited to these two implementations. The lock-free data structure memory reclamation method based on optimistic batch processing provided by these two embodiments aims to solve the synchronization problem of memory reclamation in a multi-threaded environment, and improve the performance and processing unit utilization efficiency on multi-core machines.

[0064] Example 1: A method for reclamation of lock-free data structures where each thread continuously performs deletion operations on the lock-free data structure.

[0065] Step 1: Create a lock-free data structure.

[0066] Reference Figure 2 The implementation of this step includes the following:

[0067] 1.1) Create a chained lock-free data structure that satisfies the requirement that each data node has a next pointer pointing to the next node, and that no locks are used to protect thread synchronization. This data structure can be a lock-free linked list, a lock-free skip list, a lock-free hash table, etc.

[0068] 1.2) Create a tracker, which contains a non-negative integer array of equal size to the number of threads. This tracker records the global cycle time obtained by each thread during its operation. That is, when a thread performs an operation, it records the current global cycle time. When the thread completes its operation, it sets the value at the corresponding position of the thread to null.

[0069] 1.3) Create an optimistic batch alert W, which contains a Boolean array of equal size to the number of threads. This array indicates whether the current read operation performed by a thread is safe. If the Boolean value corresponding to the thread is true, the operation is unsafe; if the Boolean value is false, the operation is safe.

[0070] 1.4) Create a global periodic recorder to allocate a monotonically increasing global periodic record Epoch∈{0,…,2} for each memory object. 64 –1}, this global period is used to represent the period in which a thread is in, or the period in which an object is inserted or deleted.

[0071] 1.5) Create an allocator to add memory objects to the data structure;

[0072] 1.6) Create a garbage collector to remove memory objects from the data structure.

[0073] Step 2: Create an object pool group.

[0074] Reference Figure 3 The implementation of this step includes the following:

[0075] For each thread, create an object pool group comprising a preparation pool, a temporary pool, and a processing pool, where:

[0076] The preparation pool is used to store objects that can be safely allocated.

[0077] Temporary pool, used to store memory objects of lock-free data structures that have been physically deleted;

[0078] The processing pool is used to process objects that were physically deleted before the start of the current phase during the reclamation process. During the reclamation process, each object in the processing pool is checked and it is determined whether the object can be safely reclaimed: if it can be reclaimed, it is moved to the preparation pool; otherwise, it is moved back to the temporary pool and processed again during the next memory reclamation.

[0079] The number of object pool groups is equal to the number of threads, with each thread corresponding to one object pool group. This ensures that multiple threads do not operate on the same object pool simultaneously, avoiding synchronization issues that may occur with concurrent threads and thus improving system processing efficiency.

[0080] Step 3: Initialize the preparation pool.

[0081] Based on the user-defined preparation pool size parameters, the system requests an equal amount of memory space from the operating system, constructs memory objects, and adds the constructed memory objects to the preparation pool, thus completing the preparation pool initialization operation for each object pool group.

[0082] Step 4: Perform a deletion operation on the memory objects in the lock-free data structure.

[0083] Reference Figure 5 The implementation of this step includes the following:

[0084] 4.1) Record the current cycle of the thread in the tracker;

[0085] 4.2) In the pointer area of ​​a memory object, mark the last two digits as 11 to indicate that the memory object has been logically deleted;

[0086] 4.3) Call the global cycle recorder to obtain the current global cycle and record it in the memory object as the deletion cycle of the memory object.

[0087] 4.4) Physically delete the memory object that has been logically deleted, that is, remove the memory object from the lock-free data structure and add it to the temporary pool of the object pool group;

[0088] 4.5) Set the value corresponding to the thread in the tracker to null to complete the deletion operation. The thread then waits to execute the next operation.

[0089] Step 5: Determine if waste recycling is needed.

[0090] The implementation of this step includes the following:

[0091] 5.1) Set the garbage collection threshold, which is the critical value that triggers the garbage collection operation. The default value is 1000, but it can also be modified by the user according to the needs of the lock-free data structure:

[0092] When better performance is required, the recycling threshold will be increased;

[0093] When memory consumption needs to be reduced, the reclamation threshold is lowered, and the preparation pool is expanded or reduced as needed. This means that users can manually increase or decrease the number of memory objects in the preparation pool, limiting the memory to be reclaimed to an acceptable range. When the number of memory objects is reduced, the released memory is returned to the operating system; when the number of memory objects is increased, a specified amount of memory is requested from the operating system and added to the thread's preparation pool.

[0094] 5.2) Determine if the user has explicitly specified recycling or if the recycling threshold has been reached:

[0095] If the number of memory objects accumulated in the temporary pool reaches the recycling threshold, garbage collection will be performed and all memory objects in the temporary pool will be moved to the processing pool.

[0096] If the user explicitly specifies recycling, garbage collection will be performed, and all memory objects in the temporary pool will be moved to the processing pool.

[0097] If the user does not explicitly specify recycling and the recycling threshold has not been reached, the deletion operation is completed, and the thread waits to execute the next operation.

[0098] Step 6: Perform the garbage collection operation.

[0099] Reference Figure 6 The implementation of this step includes the following:

[0100] 6.1) Call the tracer to record the cycle of all threads and obtain the thread with the shortest cycle R among all threads. low And the thread cycle with the longest duration R high Therefore, the range of the thread is R = [R low ,R high ];

[0101] 6.2) Call the optimistic batch alerter to set the reclamation flag of all threads to true, indicating that a certain thread has triggered a memory reclamation operation. When other threads read that the corresponding flag is true, they will roll back the unfinished operation and re-execute it.

[0102] 6.3) Retrieve the first object added to the processing pool and, based on the insertion cycle recorded at the time of insertion. The deletion cycle recorded during logical deletion Obtain its lifecycle

[0103] 6.4) Determine whether the memory object can be safely reclaimed based on its lifecycle E:

[0104] If the lifetime of a memory object is empty, it can be safely reclaimed and moved directly into the preparation pool.

[0105] if That is, if the lifecycle E of a memory object has no overlap with the scope R of the thread, the memory object can be safely reclaimed and moved to the preparation pool.

[0106] Otherwise, the memory object cannot be safely reclaimed temporarily and is moved to the temporary pool for processing in the next stage;

[0107] 6.5) Determine if the processing pool is empty:

[0108] If the processing pool is not empty, return to step 6.3);

[0109] If the processing pool is empty, the garbage collection operation is complete, and the thread waits to execute the next operation.

[0110] Example 2: A method for reclamation of lock-free data structures where each thread continuously performs insertion operations on the lock-free data structure.

[0111] Step 1: Create a lock-free data structure.

[0112] The implementation of this step is the same as step 1 in Example 1.

[0113] Step 2: Create an object pool group.

[0114] The implementation of this step is the same as step 2 in Example 1.

[0115] Step 3: Initialize the preparation pool.

[0116] The implementation of this step is the same as step 3 in Example 1.

[0117] Step 4: Perform different operations on the memory object.

[0118] Determine if a memory object can be obtained from the preparation pool of its corresponding object pool group:

[0119] If the pool is not empty, meaning that memory objects can be obtained from it, then proceed to step 5.

[0120] If the preparation pool is empty, meaning no memory object can be obtained from it, then all memory objects in the temporary pool are moved to the processing pool, and the process jumps to step 6.

[0121] Step 5: Perform the insertion operation.

[0122] Reference Figure 4 The implementation of this step includes the following:

[0123] 5.a) Record the current cycle of the thread in the tracker;

[0124] 5.b) Retrieve the required memory object from the preparation pool, and call the global cycle recorder to obtain the current global cycle, recording it in the memory object as the allocation cycle of that memory object.

[0125] 5.c) Add the memory object to the lock-free data structure;

[0126] 5.d) Set the value corresponding to the thread in the tracker to null, complete the insertion operation, and the thread returns to step 4 to wait for the next operation.

[0127] Step 6: Waste recycling operation.

[0128] Reference Figure 6 The implementation of this step includes the following:

[0129] 6.a) Call the tracer to record the cycle of all threads and obtain the thread with the shortest cycle R among all threads. low And the thread cycle with the longest duration R high Therefore, the range of the thread is R = [R low ,R high ];

[0130] 6.b) Invoke the optimistic batch alerter to set the reclamation flag of all threads to true, indicating that a certain thread has triggered a memory reclamation operation. When other threads read that the corresponding flag is true, they will roll back the unfinished operation and re-execute it;

[0131] 6.c) Retrieve the first object added to the processing pool and, based on the insertion cycle recorded at the time of insertion. The deletion cycle recorded during logical deletion Obtain its lifecycle

[0132] 6.d) Determine whether the memory object can be safely reclaimed based on its lifecycle E:

[0133] If the lifetime of a memory object is empty, or The memory object can then be safely reclaimed and moved directly into the preparation pool.

[0134] Otherwise, the memory object cannot be safely reclaimed temporarily and is moved to the temporary pool for processing in the next stage;

[0135] 6.e) Determine if the processing pool is empty:

[0136] If the processing pool is not empty, return to step 6.c);

[0137] If the processing pool is empty, the waste collection operation is complete, proceed to step 7.

[0138] Step 7: Re-execute the insertion operation.

[0139] Reference Figure 4 The implementation of this step includes the following:

[0140] 7.a) Record the current cycle of the thread in the tracker;

[0141] 7.b) Retrieve the required memory object from the preparation pool, and call the global cycle recorder to obtain the current global cycle, recording it in the memory object as the allocation cycle of that memory object.

[0142] 7.c) Add the memory object to the lock-free data structure;

[0143] 7.d) Set the value corresponding to the thread in the tracker to null, complete the insertion operation, and the thread returns to step 4 to wait for the next operation.

[0144] The numbers used for the above steps are for clearly describing the implementation scheme of the embodiments of the present invention, and their order is not limited.

[0145] The above description is merely two specific examples of the present invention and does not constitute any limitation on the present invention. Obviously, those skilled in the art, after understanding the content and principles of the present invention, may make various modifications and changes in form and details without departing from the principles and structure of the present invention. However, these modifications and changes based on the ideas of the present invention are still within the scope of protection of the claims of the present invention.

Claims

1. A lock-free data structure memory reclamation method based on optimistic batch processing, characterized in that, Includes the following steps: (1) Create a chained lockless data structure that includes an optimistic batch alerter, a tracker, a global cycle recorder, an allocator, and a reclaimer; (2) Create an object pool group equal to the number of threads. Each thread's object pool group includes a preparation pool, a temporary pool, and a processing pool. (3) Perform initialization operations on the preparation pool in each object pool group; (4) Based on the business needs of the users of this lock-free data structure, create several worker threads. Each thread continuously performs deletion or insertion operations on the lock-free data structure. For each operation, first determine the operation that the thread is to perform: If it is an insertion operation, then determine whether the memory object can be obtained from the corresponding object pool: If it can be obtained, that is, the preparation pool is not empty, then jump to step (7); If it cannot be obtained, that is, the preparation pool is empty, then proceed to step (5); If it is a deletion operation, execute the deletion operation directly, and then determine whether the user has explicitly specified recycling or the recycling threshold has been reached: If the user explicitly specifies recycling or the recycling threshold is reached, then proceed to step (5); If the user does not explicitly specify and the recycling threshold has not been reached, proceed to step (7); (5) Determine whether to perform memory reclamation based on the state of the object pool corresponding to the thread: If the preparation pool memory corresponding to the thread is sufficient, there is no need to trigger memory reclamation. If there are no objects available for allocation in the preparation pool corresponding to the thread, or if the number of objects in the temporary pool reaches the recycling threshold, the recycling operation of the thread is triggered, and all memory objects in the temporary pool are moved into the processing pool and step (6) is executed. If a thread actively requests memory reclamation or reaches the reclamation threshold, a memory reclamation operation is triggered, moving all memory objects in the temporary pool into the processing pool and executing step (6). (6) Perform garbage collection on the thread object pool group: (6a) Call the tracer to record the cycle of all threads and obtain the cycle R of the thread with the shortest cycle among all threads. low And the thread cycle with the longest duration R high That is, the range of the thread R = [R low ,R high ]; (6b) Call the optimistic batch alerter to set the reclamation flag of all threads to true, indicating that a certain thread has triggered a memory reclamation operation; when other threads read that the corresponding flag is true, they will roll back the unfinished operation and re-execute it. (6c) Retrieve the first object added to the processing pool, based on the insertion cycle recorded at the time of insertion. The deletion cycle recorded during logical deletion Obtain its lifecycle (6d) Determine whether the memory object can be safely reclaimed based on its lifecycle E: If the lifetime of a memory object is empty, it can be safely reclaimed and moved directly into the preparation pool. if That is, if the lifecycle E of a memory object has no overlap with the scope R of the thread, the memory object can be safely reclaimed and moved to the preparation pool. Otherwise, the memory object cannot be safely reclaimed temporarily and is moved to the temporary pool for processing in the next stage; (6e) Determine if the processing pool is empty: If the processing pool is not empty, return (6c); If the processing pool is empty, the garbage collection operation is complete, and step (7) is executed; (7) Based on the insertion or deletion operation performed on the lock-free data structure, determine the subsequent operation to be performed: If an insertion operation is performed on a lock-free data structure, the thread first obtains the memory object from the corresponding object pool, inserts the memory object into the lock-free data structure, and then returns to step (4) to wait for the next insertion or deletion operation. If a lock-free data structure performs a deletion operation, it returns directly to step (4) to wait for the next insertion or deletion operation.

2. The method according to claim 1, characterized in that, The tracker created in step (1) contains a non-negative integer array. The size of the array is equal to the number of threads. It is used to record the global cycle obtained by each thread during operation. That is, when a thread performs an operation, it records the current global cycle. When the thread completes the operation, it sets the value at the corresponding position of the thread to null.

3. The method according to claim 1, characterized in that, The optimistic batch alert W created in step (1) contains a Boolean array whose size is equal to the number of threads. This array is used to indicate whether the current read operation performed by the thread is safe. If the Boolean value corresponding to the thread is true, the operation is unsafe; if the Boolean value is false, the operation is safe.

4. The method according to claim 1, characterized in that, The global periodic recorder created in step (1) is used to allocate a monotonically increasing global periodic record Epoch∈{0,…,2} for each memory object. 64 –1}, this global period is used to represent the period in which a thread is in, or the period in which an object is inserted or deleted.

5. The method according to claim 1, characterized in that, The allocator and garbage collector created in step (1) are used to add memory objects from the object pool to the data structure and objects from the data structure to the object pool, respectively.

6. The method according to claim 1, characterized in that, The three pools that constitute each thread object pool group in step (2) perform the following tasks respectively: The preparation pool is used to store objects that can be safely allocated; The temporary storage pool is used to store memory objects that have been physically deleted from lock-free data structures; The processing pool is used to process objects that were physically deleted before the start of the current phase during the recycling process. During the recycling process, each object in the processing pool is checked and it is determined whether the object can be safely recycled. If it can be recycled, it is moved to the preparation pool. Otherwise, move it back to the temporary pool and process it again during the next memory reclamation.

7. The method according to claim 1, characterized in that, In step (3), the initialization operation is performed on the preparation pool in each object pool group. This involves requesting an equal amount of memory space from the operating system based on the preparation pool size parameter set by the user, constructing memory objects, and adding the constructed memory objects to the preparation pool.

8. The method according to claim 1, characterized in that, The deletion operations performed by each thread on the lock-free data structure in step (4) include the following: (4a) Record the current cycle of the thread in the tracker; (4b) In the pointer area of ​​the memory object, mark the last two bits as 11 to indicate that the memory object has been logically deleted; (4c) Call the global cycle recorder to obtain the current global cycle and record it in the memory object as the deletion cycle of the memory object. (4d) Physically delete the memory object that has been logically deleted, that is, remove the memory object from the lock-free data structure and add it to the temporary pool of the object pool group. (4e) Set the value corresponding to the thread in the tracker to null to complete the deletion operation.

9. The method according to claim 1, characterized in that, The insertion operations performed by each thread on the lock-free data structure in step (4) include the following: (4a') Record the current cycle of the thread in the tracker; (4b') Retrieve the required memory object from the preparation pool, and call the global cycle recorder to obtain the current global cycle, and record it in the memory object as the allocation cycle of the memory object. (4c') Add the memory object to the lock-free data structure; (4d') Set the value corresponding to the thread in the tracker to null to complete this insertion operation.

10. The method according to claim 1, characterized in that, The recycling threshold in step (4) refers to the critical value that triggers the garbage collection operation. It is set according to the requirements of the lock-free data structure, with a default value of 1000. When the number of memory objects accumulated in the temporary pool reaches the recycling threshold, the next deletion operation will trigger the garbage collection operation. This recycling threshold can be modified by the user: When better performance is required, the recycling threshold will be increased; When it is necessary to reduce memory consumption, the reclamation threshold will be lowered, and the preparation pool will be expanded or shrunk as needed. The scaling up or down of the preparation pool refers to the user manually increasing or decreasing the number of memory objects in the preparation pool to limit the memory to be reclaimed to an acceptable range. When the number of memory objects is reduced, the released memory is returned to the operating system. When the number of memory objects increases, a specified amount of memory is requested from the operating system and added to the thread's preparation pool.

Images