Data processing method and computer equipment

Abstract

The embodiment of the invention provides a data processing method and computer equipment, which can be applied to the field of data processing, and comprises the following steps: when a reader calls an interface entering a read critical zone, updating a local first variable (representing whether the reader enters the read critical zone) of the reader to a second state, the read critical zone is configured to enable the recoverer to determine an end moment of the grace period based on the first variable, and execute the read critical zone under the condition that a second variable (representing whether the recoverer is in a state waiting for all readers to leave the grace period) local to the reader is a third state. According to the method, the useless hardware memory barrier is eliminated by additionally adding two variables in each reader, and the timely recovery of the memory is realized. According to the method, the hardware memory barrier is executed only when the recoverer exists, and the read critical zone is directly executed when the recoverer does not exist, so that the execution times of the hardware memory barrier are reduced through the on-demand execution mode, and the performance overhead of the hardware memory barrier in a normal path is avoided while the correctness is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer data processing, and in particular to a data processing method and a computer device. BACKGROUND

[0002] Read Copy Update (RCU) is a classic lock-free data synchronization mechanism. The RCU mechanism is widely used in Linux kernel and other basic software, and has important significance in improving the performance scalability of software in multi-core systems and the non-blocking of real-time scenarios. The core of the RCU mechanism is to update the data structure content through atomic operations, so that the newly added / modified / deleted content is atomically seen by the reader thread (hereinafter referred to as reader). That is, the reader can correctly read the updated data, or cannot read it. There is no half-updated data or incorrect data read.

[0003] Although RCU solves the atomic update between the reader and the writer thread (hereinafter referred to as writer) without blocking each other, the main technical difficulty of RCU is when the modified / deleted target node (such as node X) can be recycled, that is, how to achieve safe memory reclamation. RCU uses a grace period to track when the target node can be recycled. Specifically, RCU requires all readers to use rcu_read_lock and rcu_read_unlock to wrap the code segment that reads shared data, which is called the read critical section. When the last reader who may see the target node leaves the read critical section, the target node can be safely deleted. As shown in FIG. 1, the thread that modifies / deletes the target node (hereinafter referred to as the syncer thread or syncer) often needs to track the readers (such as Reader 0 and Reader 1 in FIG. 1) that enter the read critical section before the pointer is updated (i.e., at T1). These readers may read node X along the linked list. When the last reader who may read node X leaves the read critical section, node X can be deleted by the syncer (Reader 3 enters the read critical section after T1, and cannot see node X). The syncer blocks and waits for the reader by calling the synchronize_rcu interface. When the interface returns, it means that all waiting readers have left the read critical section, and the syncer can safely recycle node X. This mechanism is also an epoch-based memory reclamation mechanism. Figure 1 Figure 1

[0004] ​​In summary, the key core points of the RCU technology are as follows: 1) to implement a grace period tracking mechanism with extremely low overhead (i.e., rcu_read_lock / rcu_read_unlock with extremely low overhead), so as to ensure high performance and high scalability of readers in a "read more and write less" scenario; and 2) to ensure the accuracy and timeliness of the grace period identification, so as to avoid waiting for too long and being unable to delete. Some existing technical solutions are dedicated to solving the above two key core points, but at the same time, there are some common performance problems: when the reader enters the read critical section, it needs to use the write / read hardware memory barrier (in ARM architecture, it is a complete memory barrier, and the corresponding instruction is dmb ish) every time, which has a serious impact on performance and causes serious performance overhead. SUMMARY

[0005] The present application provides a data processing method and a computer device. The useless hardware memory barrier is eliminated by additionally adding two variables in each reader thread (taking the first thread as an example), and the memory is recycled in time, that is, the state of the first variable is used to determine when the recycler thread (taking the second thread as an example) ends the grace period so as to recycle the memory in time, and the state of the second variable is used to determine whether the hardware memory barrier needs to be executed. The present application only executes the hardware memory barrier when the recycler thread works, and directly executes the read critical section when there is no recycler thread working, so as to ensure correctness while avoiding the performance overhead of the hardware memory barrier in the normal path.

[0006] Based on this, the embodiments of the present application provide the following technical solutions:

[0007] In a first aspect, the present application first provides a data processing method, which is applied to a computer device and runs a first thread and a second thread on the computer device, wherein the first thread belongs to a reader and the second thread belongs to a recycler. The method specifically includes:

[0008] A code segment (which can be referred to as a first code segment) run by the first thread is used to perform the following operation (which can be referred to as a first operation):

[0009] Firstly, when the first thread needs to enter the read critical section, a first interface for entering the read critical section is called to enter the corresponding read critical section. Then, a first variable local to the first thread is updated from a default first state to a second state, so that the second thread as a reaper determines an end time of the grace period (i.e., when to end the grace period) based on the current state of the first variable, so as to timely reclaim the memory. The first variable is used to represent whether the first thread enters the read critical section, the first state indicates that the first thread does not enter the read critical section, and the second state indicates that the first thread has entered the read critical section. Finally, it is determined whether a second variable local to the first thread is in a third state, and if the second variable local to the first thread is in the third state, the corresponding read critical section is directly executed. The second variable is used to represent whether the second thread is in a state of waiting for all readers corresponding to the reaper to leave the grace period, and the third state indicates that the second thread is not in the state of waiting for all readers corresponding to the reaper to leave the grace period.

[0010] In the above embodiments of the present application, for the write / read hardware memory barrier with serious performance overhead, the hardware memory barrier is executed on demand. By adding two variables in each reader thread (i.e., the first thread), the useless hardware memory barrier is eliminated, and the memory is timely reclaimed, i.e., the state of the first variable is used to determine when the reaper thread (i.e., the second thread) ends the grace period so as to timely reclaim the memory, and the state of the second variable is used to determine whether the hardware memory barrier needs to be executed. The present application directly executes the read critical section when there is no reaper thread working (because in the "read more and write less" scenario of the lock-free synchronization (RCU-like mechanism), most of the time is that the reader thread calls the interface to execute the read critical section, and the writer is rarely (i.e., the situation of triggering the reaper thread to work is also rare), so the hardware memory barrier is not needed in most scenarios), thereby ensuring correctness while avoiding the performance overhead of the hardware memory barrier in the normal path.

[0011] In a possible implementation of the first aspect, the first operation further includes: if the second variable local to the first thread is in a fourth state, executing a first hardware memory barrier. After executing the first hardware memory barrier, the operation of the read critical section is executed. The fourth state indicates that the second thread is in a state of waiting for the reader thread to leave the grace period.

[0012] In the above embodiments of the present application, the hardware memory barrier is executed only when the reaper thread is working (i.e., the fourth state), and this on-demand execution can avoid excessive use of the hardware memory barrier and improve the throughput.

[0013] In a possible implementation of the first aspect, the first operation further includes: before executing the first hardware memory barrier, updating a time stamp local to the first thread to a first time stamp.

[0014] In the above-mentioned embodiments of the present application, the time stamp local to each reader thread (i.e., the first thread) is independently updated, so that the recycler thread (i.e., the second thread) and each reader thread can achieve independent synchronization without global sharing, while achieving precise tracking of the grace period and completely avoiding unnecessary performance overhead caused by false sharing.

[0015] In a possible implementation of the first aspect, the first operation further includes: after executing the read critical section, invoking a second interface for exiting the read critical section to exit the read critical section, and executing a release hardware memory barrier. The release hardware memory barrier is a special memory barrier.

[0016] In the above-mentioned embodiments of the present application, the release hardware memory barrier is further executed when the reader thread exits the read critical section, to ensure the order of the preceding read / write operation and the current write operation. Since the release hardware memory barrier has a small overhead, it does not affect performance.

[0017] In a possible implementation of the first aspect, after invoking the second interface for exiting the read critical section to exit the read critical section, the first operation further includes: updating the first variable from the second state to the first state. If the second variable is not in the third state, the second variable is further updated to the third state; if the second variable is in the third state, the third state is kept unchanged.

[0018] In the above-mentioned embodiments of the present application, when the reader thread exits the read critical section, the states of the two variables are both updated to the default state, i.e., the first variable is changed to the first state and the second variable is changed to the third state, to facilitate other recycler threads to correctly calculate a new grace period.

[0019] In a possible implementation of the first aspect, after executing the release hardware memory barrier, the first operation further includes: in the case where the second variable is updated to the third state, directly exiting the read critical section.

[0020] In the above-mentioned embodiments of the present application, in the process of the reader thread exiting the read critical section, if there is no recycler (i.e., the second variable is in the third state before being updated) before the state variable is updated, the read critical section is directly exited, so as to ensure correctness while avoiding the performance overhead of the hardware memory barrier in the normal path.

[0021] In a possible implementation of the first aspect, after executing the release hardware memory barrier, the first operation further includes: in the case where the second variable is not updated to the third state (i.e., is updated to the fourth state) before being updated, executing a second hardware memory barrier, and then exiting the read critical section.

[0022] In the above-mentioned embodiments of the present application, the hardware memory barrier is executed only when the reclaimer thread is working (i.e. the fourth state), and this on-demand execution can avoid overuse of the hardware memory barrier and improve the throughput.

[0023] In a possible implementation of the first aspect, before the second hardware memory barrier is executed, the first operation further includes: updating the time stamp local to the first thread as the second time stamp.

[0024] In the above-mentioned embodiments of the present application, the time stamp local to each reader thread (i.e. the first thread) is updated independently, so that the reclaimer thread (i.e. the second thread) and each reader thread can be synchronized independently without global sharing, and at the same time, the wide margin period can be tracked accurately, and the performance overhead caused by unnecessary false sharing can be completely avoided.

[0025] In a possible implementation of the first aspect, the first update time is later than the second update time, where the first update time is the time when the time stamp local to the first thread is updated as the second time stamp, and the second update time is the time when the second variable is updated as the third state without the second variable being the third state.

[0026] In the above-mentioned embodiments of the present application, the update time of the time stamp local to the reader thread is later than the update time of the second variable, which is to prevent the out-of-order of the read operation in the critical section and the time stamp update operation, so as to ensure the correctness.

[0027] The second aspect of the present application further provides a data processing method, which is applied to a computer device, and n (n≥2) first threads and a second thread are running on the computer device, the first threads belong to reader threads, and the second thread belongs to a reclaimer thread, and the method specifically includes:

[0028] The second thread runs a code segment (which can be referred to as a second code segment) to execute an operation (which can be referred to as a second operation):

[0029] Firstly, n first variables local to n first threads and n third timestamps local to the n first threads are acquired, the third timestamps being the timestamps of the first threads recorded by the second thread at the current acquisition time, and the first variables being used to represent whether the first threads enter a read critical section, including two states, a first state indicating that the first threads do not enter the read critical section, and a second state indicating that the first threads have entered the read critical section. Then, m first threads and m third timestamps local to the m first threads are determined according to the n first variables, where the current states of the m first variables of the m first threads are all the second state, and m is greater than or equal to 1. Finally, the memory corresponding to the grace period is recycled in a case where a fourth timestamp local to a target first thread at a current time of the target first thread is greater than the third timestamp of the target first thread, where the target first thread is any one of the m first threads.

[0030] In the above embodiments of the present application, it is specifically described how the recycler thread (i.e., the second thread) recycles the corresponding memory in time after the end of the grace period based on the first variables on each reader thread (i.e., the first thread) and the determination of the end of the grace period, thereby ensuring the accuracy and timeliness of the grace period identification and avoiding long waiting time for deletion. In addition, the timestamps of each reader thread and the recycler thread are independently synchronized, avoiding access and modification of the global shared variable and improving the throughput.

[0031] In a possible implementation form of the second aspect, before the m first threads and the m third timestamps local to the m first threads are determined according to the n first variables, the second operation further includes: updating states of n second variables local to the n first threads to a fourth state, the fourth state indicating that the second thread is in a state of waiting for the reader thread to leave the grace period, one first thread corresponding to one second variable.

[0032] In the above embodiments of the present application, the recycler thread also needs to update the states of the second variables of the reader threads, so that the reader threads can timely perceive that the recycler is in the state of waiting for the reader thread to leave the grace period.

[0033] In a possible implementation form of the second aspect, one implementation form of updating the states of the n second variables local to the n first threads to the fourth state can be: updating the states of the n second variables local to the n first threads to the fourth state through an atomic compare and replace operation (Compare And Swap).

[0034] In the above embodiments of the present application, a specific implementation form of the updating mode is specifically described, which is feasible.

[0035] In a possible implementation manner of the second aspect, after the n first variables local to the n first threads and the n third time stamps local to the n first threads are acquired, the second operation further includes: performing a third hardware memory barrier.

[0036] In the above-mentioned embodiments of the present application, the garbage collector thread also needs to perform a hardware memory barrier when the garbage collector thread is working. This manner of performing a hardware memory barrier only when the garbage collector is working can avoid excessive use of hardware memory barriers and improve the throughput.

[0037] The third aspect of the present application provides a computer device having a function of implementing the method of the first aspect or any one of the possible implementation manners of the first aspect, or having a function of implementing the method of the second aspect or any one of the possible implementation manners of the second aspect. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-mentioned functions.

[0038] The fourth aspect of the present application provides a computer device, which can include a memory, a processor and a bus system. The memory is used to store a computer program (also referred to as a program or computer readable instruction). The processor is used to call the program stored in the memory to execute the method of the first aspect or any one of the possible implementation manners of the first aspect of the present application, or to call the program stored in the memory to execute the method of the second aspect or any one of the possible implementation manners of the second aspect of the present application.

[0039] The fifth aspect of the present application provides a computer readable storage medium, which stores instructions. When the instructions run on a computer, the computer can execute the method of the first aspect or any one of the possible implementation manners of the first aspect, or the computer can execute the method of the second aspect or any one of the possible implementation manners of the second aspect.

[0040] The sixth aspect of the present application provides a computer program or a computer program product containing instructions. When the computer program or the computer program product runs on a computer, the computer executes the method of the first aspect or any one of the possible implementation manners of the first aspect, or the computer can execute the method of the second aspect or any one of the possible implementation manners of the second aspect.

[0041] In a seventh aspect, the present application provides a chip comprising at least one processor and at least one interface circuit coupled to the processor, the at least one interface circuit being configured to perform a transceiving function and send instructions to the at least one processor, and the at least one processor being configured to run a computer program or instructions having a function of implementing the method of the first aspect or any possible implementation of the first aspect, or having a function of implementing the method of the second aspect or any possible implementation of the second aspect. The function can be implemented by hardware, software, or a combination of hardware and software, and the hardware or software includes one or more modules corresponding to the above functions. In addition, the interface circuit is configured to communicate with other modules outside the chip.

[0042] In some implementations of the present application, some of the processors in the one or more processors can be implemented by dedicated hardware to perform some steps in the above method, for example, processing related to a neural network model can be implemented by a dedicated neural network processor or a graphics processor.

[0043] The method provided by the embodiments of the present application can be implemented by one chip or by multiple chips in cooperation. BRIEF DESCRIPTION OF DRAWINGS

[0044] Figure 1 An example diagram of the grace period of the RCU provided by the embodiments of the present application;

[0045] Figure 2 A schematic diagram of the system architecture provided by the embodiments of the present application;

[0046] Figure 3 An example diagram of the state variable representation method provided by the embodiments of the present application;

[0047] Figure 4 A flowchart of the data processing method provided by the embodiments of the present application;

[0048] Figure 5 A flowchart of the reader entering the read critical section provided by the embodiments of the present application and deployed with the GDump module;

[0049] Figure 6 A flowchart of the reader exiting the read critical section provided by the embodiments of the present application and deployed with the GDump module;

[0050] Figure 7 Another flowchart of the data processing method provided by the embodiments of the present application;

[0051] Figure 8A flowchart provided by the embodiment of the present application shows a process in which the retriever waits for all readers having the GDump module deployed to leave the grace period;

[0052] Figure 9 A result comparison chart provided by the embodiment of the present application shows a GDump and URCU micro-benchmark test;

[0053] Figure 10 A result comparison chart provided by the embodiment of the present application shows a GDump and URCU linked list test;

[0054] Figure 11 An application program relationship diagram provided by the embodiment of the present application uses the GDump;

[0055] Figure 12 A structural diagram of a computer device provided by the embodiment of the present application;

[0056] Figure 13 Another structural diagram of a computer device provided by the embodiment of the present application;

[0057] Figure 14 Another structural diagram of a computer device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0058] The present application provides a data processing method and a computer device, which eliminates useless hardware memory barriers by additionally adding two variables in each reader thread (taking a first thread as an example), and realizes timely memory recovery, i.e., determining when a retriever thread (taking a second thread as an example) ends the grace period to recover the memory in time through the state of a first variable, and determining whether to execute a hardware memory barrier through the state of a second variable. The present application executes the hardware memory barrier only when the retriever thread works, and directly executes the read critical section when the retriever thread does not work, which reduces the execution times of the hardware memory barrier, thereby avoiding the performance overhead of the hardware memory barrier in the normal path while ensuring correctness.

[0059] The terms "first", "second", etc. in the specification and claims of the present application and in the above-described drawings are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that the terms thus used can be interchanged under appropriate circumstances, which is only a distinguishing way used in the description of the embodiments of the present application to describe the objects with the same properties. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, so that the processes, methods, systems, products or devices containing a series of units do not have to be limited to those units, but can include other units not clearly listed or inherent to the processes, methods, products or devices.

[0060] The embodiments of the present application are described below in conjunction with the accompanying drawings. It is obvious to those skilled in the art that the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems with the development of technology and the emergence of new scenarios.

[0061] First, the system architecture and the overall flow to which the method of the embodiments of the present application is applied are described. For details, please refer to Figure 2 , Figure 2 An example of the system architecture provided by the embodiments of the present application is shown in the figure, which includes n readers (such as T1 thread, T2 thread, …, Tn thread) and recyclers corresponding to the n readers. The following are introduced respectively: Figure 2

[0062] (1) Reader

[0063] Each reader contains a GDump module, and the GDump module of each reader includes a local private state variable and a local private timestamp. The state variable can specifically include a first variable and a second variable, wherein the first variable is used to represent whether the reader enters a read critical section, and the second variable is used to represent whether the recycler is in a state of waiting for the reader to leave the grace period (i.e., whether the recycler is in a working state). Each local private timestamp is used to represent whether the second variable of the current reader is updated by the recycler.

[0064] As an example, the state variable can be represented by two bits (i.e., the case shown in Figure 2 ). In this case, the update of the state variable is to update both bits at the same time, one bit corresponding to the first variable and the other bit corresponding to the second variable. The two bits respectively represent whether the current reader is in a read critical section (hereinafter referred to as whether there is a reader, and the bit is marked by the reader) and whether the recycler corresponding to the current reader is in a state of waiting for the grace period to end (hereinafter referred to as whether there is a recycler, and the bit is marked by the corresponding recycler). For example, the high-bit bit can be the bit of the recycler, and when the recycler corresponding to the current reader is in a working state, this bit is 1, otherwise it is 0; the low-bit bit is the bit of the reader, and when the current reader is in a read critical section, this bit is 1, otherwise it is 0. For ease of understanding, please refer to the example shown in Figure 3 , wherein 0b00 represents that there is no reader and no recycler, 0b01 represents that there is a reader, 0b10 represents that there is a recycler, and 0b11 represents that there is a reader and a recycler at the same time.

[0065] ​It should be noted that in the embodiments of the present application, the low bit can also be the bit of the recycler, and the high bit can be the bit of the reader, and the present application does not limit this.

[0066] It should be noted that in some embodiments of the present application, the first variable and the second variable can also exist independently, but when updating the state variable, they need to be updated at the same time (such as through atomic operation) to ensure correctness.

[0067] (2) Recycler

[0068] The local of the recycler (i.e., the syncer) saves the corresponding n reader time stamp backups (such as T1.ts, T1.ts, …, Tn.ts in Figure 2 ) on demand when recycling, and judges whether each reader exits the read critical section in turn.

[0069] It should be noted that, Figure 2 The same type of GDump module described in the system architecture of the corresponding embodiment is deployed on n readers. In actual application, there can be multiple types of GDump modules, and different types of GDump modules can be identified by different identifiers during initialization. The GDump modules deployed on each reader can be different, and only the readers belonging to the same type of GDump module correspond to the same recycler (i.e., they correspond to one GDump recycling process (similar to one lock), and the specific recycler (i.e., who calls this process) does not need to be determined), and one recycler can manage multiple GDump modules. The recycler can be multiple or a writer, and the present application does not limit this. For example, assuming that the GDump modules deployed in T1' thread, T2' thread, …, Tm' thread belong to the same type 1, and are different from the type 2 of the GDump modules in Figure 2 , then T1' thread, T2' thread, …, Tm' thread and the corresponding recycler constitute another similar system architecture, and details are not described here.

[0070] It should be noted that in the embodiments of the present application, Figure 2 The system architecture of the present application is only schematic, and the deployment manner of each unit / module is not limited.

[0071] The embodiments of the present application mainly relate to three core processes, which are: 1) a reader with a GDump module enters a read critical section (which can be recorded as GDump_enter), the reader must call the interface to mark into the read critical section before reading data; 2) a reader with a GDump module leaves the read critical section (which can be recorded as GDump_exit), the reader must call the interface to mark out of the read critical section after reading data; and 3) a reclaimer corresponding to the GDump module waits for all readers to leave the grace period to end (which can be recorded as GDump_synchronize).

[0072] On the basis of the system architecture and in combination with the three core processes described above, the method for processing data provided by the embodiments of the present application is introduced. The method is applied to a computer device, and a first thread and a second thread are run on the computer device, wherein the first thread belongs to a reader, and the second thread belongs to a reclaimer. For details, please refer to Figure 4 , Figure 4 A flowchart of the method for processing data provided by the embodiments of the present application is shown in the figure. The method can specifically include the following steps:

[0073] A code segment (which can be referred to as a first code segment) run by the first thread is used to perform the following operation (which can be referred to as a first operation):

[0074] 401. A first interface for entering a read critical section is called to enter the read critical section.

[0075] When the first thread needs to enter the read critical section, the interface for entering the read critical section (which can be referred to as a first interface) is called first to enter the corresponding read critical section.

[0076] 402. A first variable local to the first thread is updated from a first state to a second state, so that the second thread determines the end time of the grace period based on the first variable.

[0077] Then, the first variable local to the first thread is updated from a default first state to a second state, so that the second thread as a reclaimer determines the end time of the grace period (i.e., when to end the grace period) based on the current state of the first variable, so as to timely reclaim memory. The first variable is used to represent whether the first thread enters the read critical section, the first state indicates that the first thread does not enter the read critical section, and the second state indicates that the first thread has entered the read critical section.

[0078] It needs to be explained here that the sign of the start of the grace period is that when the writer deletes / updates the target node (taking node X as an example), the reclaimer starts to work, and the start of the work of the reclaimer means the start of the grace period. When the reclaimer is in the working state, the reclaimer can directly update the second variable (such as Figure 3The high bit in the read critical section is marked as 1 to tell each corresponding reader that a recycler is currently working. After the grace period begins, readers who enter the read critical section will not be able to see the node X that is currently being deleted / updated (the start of the grace period means that subsequent readers cannot see the node X to be reclaimed). The end of the grace period is marked as: the last reader who may see node X has completed the corresponding read critical section. Specifically, the timestamp of the reader is used to determine whether the last reader has completed the read critical section. It should be noted here that the writer and the recycler can be the same thread or different threads. If they are different threads, the recycler and the writer trigger the recycler to start working through information interaction.

[0079] It should also be noted that, in the embodiment of the present application, the initial default state of the first variable local to the first thread is the first state, that is, the first state is always the first state when the first thread does not enter the read critical section.

[0080] 403. When the second variable local to the first thread is in the third state, execute the read critical section.

[0081] Finally, it is determined whether the second variable local to the first thread is in the third state, and if it is in the third state, the corresponding read critical section is directly executed. The second variable is used to indicate whether the second thread is in a state of waiting for all readers corresponding to the recycler to leave the grace period. The third state indicates that the second thread is not in a state of waiting for all readers corresponding to the recycler to leave the grace period.

[0082] In the above embodiments of the present application, since in the "read more, write less" scenario of lock-free synchronization (RCU-like mechanism), most of the time it is readers who call the interface to execute the read critical section, and there are very few writers (that is, there are also very few situations that trigger the recycler to work). Therefore, the hardware memory barrier is not required in most scenarios. When there is no recycler working, there is no need to execute any hardware memory barrier, and its performance scalability is well guaranteed.

[0083] It should be noted that in some other embodiments of the present application, if the second variable local to the first thread is in the fourth state, a hardware memory barrier is executed once, and the hardware memory barrier can be referred to as a first hardware memory barrier. After the first hardware memory barrier is executed, the operation of reading the critical section is performed. Among them, the fourth state indicates that the second thread is in a state of waiting for the reader thread to leave the grace period. In an embodiment of the present application, the hardware memory barrier is executed only when there is a recycler thread working (i.e., the fourth state). This on-demand execution method can avoid excessive use of hardware memory barriers and improve throughput.

[0084] It should be noted that in some embodiments of the present application, the first thread local timestamp is updated to the first timestamp before the first hardware memory barrier is executed. Figure 2 For example, the timestamp is used to determine whether the reader is marked by the reclaimer (i.e., whether the second variable is in the fourth state), and if so, the reader local timestamp is updated (except for the case where the reclaimer comes after the reader finishes executing the read critical section), such as timestamp+1, which is used by the last reclaimer to determine whether the reader thread needs to be waited for or when to wait for.

[0085] The above steps 401-403 are the execution steps of the first thread calling the first interface to enter the read critical section. After the first thread finishes executing the corresponding read critical section, the first thread needs to exit the read critical section. The process of the first thread exiting the read critical section is described as follows:

[0086] After executing the read critical section, the interface for exiting the read critical section (which can be referred to as the second interface) is called to exit the read critical section, and a release hardware memory barrier is executed. The release hardware memory barrier is a special memory barrier that can guarantee the order of the previous read-write operation and the current write operation. The release hardware memory barrier needs to be executed when exiting the read critical section. Since the release hardware memory barrier has a small overhead and does not affect performance.

[0087] In addition, in some embodiments of the present application, in addition to executing the release hardware memory barrier, the state variables also need to be restored to the initial default state, i.e., the first variable is updated from the second state to the first state, and if the second variable is not in the third state, the second variable is also updated to the third state, and if the second variable is in the third state, the third state remains unchanged. Figure 2 For example, state=0b00.

[0088] It should be noted that in some embodiments of the present application, in the process of the first thread exiting the read critical section, if there is no reclaimer before the state variable is updated (i.e., the second variable is in the third state before being updated), the read critical section is directly exited. Specifically, after the release hardware memory barrier is executed, the first operation further includes: directly exiting the read critical section if the second variable is in the third state before being updated.

[0089] It should also be noted that, in some embodiments of the present application, during the process of the first thread exiting the read critical section, if there is a reclaimer before the state variable is updated (i.e., the second variable is in the fourth state before being updated), a hardware memory barrier must be executed before exiting the read critical section. Specifically, after executing the release hardware memory barrier, the first operation further includes: if the second variable is not in the third state (i.e., the fourth state) before being updated, first executing a hardware memory barrier, which can be referred to as a second hardware memory barrier, and then exiting the read critical section.

[0090] It should also be noted that in some embodiments of the present application, when the first thread exits the read critical section, if there is a reclaimer before the state variable is updated (i.e., the second variable is in the fourth state before being updated), the local timestamp of the first thread needs to be updated. This is used by the last reclaimer to determine whether it needs to wait for the first thread while waiting for the grace period to end, or when it needs to wait. Specifically, before executing the second hardware memory barrier, the local timestamp of the first thread is updated to the second timestamp.

[0091] It should be noted here that, in some embodiments of the present application, in the process of the first thread exiting the read critical section, the update time of the local timestamp must be later than the update time of the second variable. Specifically, the time when the local timestamp of the first thread is updated to the second timestamp (which can be called the first update time) must be later than the time when the second variable is updated to the third state when the second variable is not in the third state (which can be called the second update time). The purpose is to prevent the read operation and the timestamp update operation in the read critical section from being out of order to ensure correctness.

[0092] To facilitate understanding of the above process, Figure 2 On the basis of the corresponding embodiment, the process of a reader deployed with the GDump module entering the read critical section (i.e., the GDump_enter process) and the process of exiting the read critical section (i.e., the GDump_exit process) are respectively described with specific examples:

[0093] A. The process of a reader deployed with the GDump module entering the read critical section.

[0094] Please refer to the following for details: Figure 5 , Figure 5 A flowchart of a reader with a GDump module deployed in an embodiment of the present application entering a read critical section may include the following steps:

[0095] 501. Update the reader's local state variables through atomic operations.

[0096] Firstly, the state variable in the local of the reader is updated by the atomic operation to be marked as having a reader, i.e. the low bit is marked as 1, which can be expressed as: state = 0b01. In the embodiment of the present application, since the state variable includes the high bit (i.e. the second variable) and the low bit (i.e. the first variable), the update is simultaneous.

[0097] It should be noted that in the embodiment of the present application, the atomic operation can be a swap operation, i.e. the old value of the state variable is read out and a new value is put in.

[0098] 502. Determine whether there is a recycler according to the read state variable, if yes, execute step 503, if no, execute step 505.

[0099] Then, it is determined whether there is a recycler by reading out the state in step 501, i.e. whether the high bit in the state variable read out when the atomic operation swap is executed in step 501 is 1 (i.e. &0b10!= 0), if yes, execute step 503, if no, execute step 505.

[0100] 503. Atomically update the local timestamp of the reader.

[0101] The local timestamp of the reader is atomically updated, as an example, the current local timestamp = the local timestamp before update + 1.

[0102] 504. Execute a hardware memory barrier.

[0103] After the local timestamp of the reader is updated, a hardware memory barrier is executed and the high bit is reset to 0, i.e. state is updated from 0b11 to 0b01.

[0104] 505. Complete entering the read critical section.

[0105] The entering of the read critical section is completed and the read critical section is started to be executed.

[0106] In the above embodiment of the present application, in the read more than write scenario, when there is no recycler, the steps executed by the reader only include step 501 and step 502, i.e. one atomic operation on the local variable, without the need to execute any hardware memory barrier, so that the performance scalability is well guaranteed.

[0107] B. The flow of the reader with the GDump module deployed exiting the read critical section.

[0108] For details, please refer to Figure 6 , Figure 6 A flowchart of the reader with the GDump module deployed exiting the read critical section provided in the embodiment of the present application, which can specifically include the following steps:

[0109] 601. Perform a release hardware memory barrier.

[0110] First, a release hardware memory barrier is performed. The release hardware memory barrier is a special memory barrier used to guarantee the global visibility order of memory accesses of read / write operations.

[0111] It should be noted that in the embodiments of the present application, if the requirement for performance overhead is not high, a normal hardware memory barrier can also be performed, i.e., a normal hardware memory barrier is performed instead of a release hardware memory barrier, because the semantics / overhead of the release hardware memory barrier is lighter than that of the normal hardware memory barrier, and the release hardware memory barrier can be applied to an application scenario with low requirement for performance overhead.

[0112] 602. Update the state variable local to the reader through an atomic operation.

[0113] In addition to performing the release hardware memory barrier, the state variable local to the reader is atomically updated to be neither a reader nor a recycler (i.e., state=0b00).

[0114] It should be noted that in the embodiments of the present application, the atomic operation can be a swap operation, i.e., the old value of the state variable is read out and a new value is written in.

[0115] It should be noted that in the embodiments of the present application, there is no execution order between step 601 and step 602, and step 601 can be performed first and then step 602 can be performed, or step 601 and step 602 can be performed simultaneously (for example, step 601 and step 602 can be included in the same hardware instruction to achieve the case of simultaneous execution).

[0116] 603. Determine whether there is a recycler according to the read state variable, and if so, perform step 604, and if not, perform step 605.

[0117] Then, it is determined whether there is a recycler by reading out the state in step 601, i.e., it is determined whether the high bit in the state variable read when the atomic operation swap in step 601 is performed is 1 (i.e., &0b10! = 0), and if so, step 604 is performed, and if not, step 606 is performed.

[0118] 604. Atomically update the local timestamp of the reader.

[0119] The local timestamp of the reader is atomically updated. As an example, the current local timestamp = the local timestamp before update + 1.

[0120] It should be noted that the update time of the local timestamp of the reader in step 604 is later than the update time of the state variable.

[0121] 605, performing a hardware memory barrier.

[0122] The reader performs a hardware memory barrier after updating the local timestamp.

[0123] 606, completing exiting the read critical section.

[0124] After the reader performs the read critical section, the reader exits the read critical section and also needs to reset the state to zero. Specifically, if the current state = 0b01 or state = 0b11, the state is updated to state = 0b00 when the read critical section is exited.

[0125] In the above embodiments of the present application, in the read-multiple-write-few scenario, when the state variable before the atomic operation replacement indicates that there is no recycler, the steps performed by the reader only include steps 601 and 603. Although the hardware memory barrier (i.e., release hardware memory barrier) is included in step 602, it is a hardware memory barrier for ensuring reading a write operation, and the performance overhead of the hardware memory barrier is very low, which does not cause excessive influence on performance.

[0126] It should be noted that the above embodiments describe the process of how the reader enters the read critical section and how the reader exits the read critical section. Next, from the perspective of the recycler (taking the second thread as an example), the end of the grace period is determined based on the state variable of each reader (taking n first threads as an example, n≥2) and the timestamp, and the corresponding memory is recycled in time after the grace period ends. For details, please refer to Figure 7 , Figure 7 Another flowchart of the data processing method provided by the embodiments of the present application is provided. The flowchart can be executed after steps 401-403 described above, and can specifically include the following steps:

[0127] A code segment (which can be referred to as a second code segment) run by the second thread is used to perform the following operation (which can be referred to as a second operation):

[0128] 701, obtaining n first variables local to n first threads and n third timestamps local to the n first threads, one first thread corresponding to one first variable and one third timestamp.

[0129] First, n first variables local to n first threads and n timestamps (which can be referred to as third timestamps) local to the n first threads are obtained. The third timestamp is the timestamp local to the first thread recorded by the second thread at the current acquisition time, and the first variable is used to represent whether the first thread has entered the read critical section, which includes two states. The first state indicates that the first thread has not entered the read critical section, and the second state indicates that the first thread has entered the read critical section.

[0130] It should be noted that in some embodiments of the present application, after obtaining the n first variables local to the n first threads and the n third time stamps local to the n first threads, a hardware memory barrier, which can be referred to as a third hardware memory barrier, can be executed. The manner in which the hardware memory barrier is executed only when there is a reclaimer (i.e., the second thread) can avoid excessive use of the hardware memory barrier and improve throughput.

[0131] 702. Determine the m first threads and the m third time stamps local to the m first threads according to the n first variables.

[0132] Then, the m first threads and the m third time stamps local to the m first threads are further determined according to the n first variables, where the current state of the m first variables of the m first threads is the second state, and m≥1.

[0133] Specifically, in some embodiments of the present application, first, it can be determined according to the obtained n first variables which first variables have the second state. Assuming that m first variables have the second state, the m first threads corresponding to the m first variables can be determined based on the m first variables (because one first thread corresponds to one first variable), and the m third time stamps corresponding to the m first threads can be determined (because one first thread corresponds to one third time stamp), and m third time stamps are obtained in total.

[0134] 703. In the case where the fourth time stamp local to the target first thread at the current time is greater than the third time stamp of the target first thread, the memory corresponding to the grace period is recycled, and the target first thread is any one of the m first threads.

[0135] Finally, in the case where the fourth time stamp local to the target first thread at the current time is greater than the third time stamp of the target first thread, the memory corresponding to the grace period is recycled. Wherein the target first thread is any one of the m first threads.

[0136] Specifically, in some embodiments of the present application, first, it can be determined whether the time stamp (i.e., the fourth time stamp) of the m first threads at the current time is greater than the third time stamp recorded when the second thread obtains it. If the fourth time stamp of each first thread is greater than the corresponding third time stamp, it means that the grace period is over, and the memory corresponding to the grace period can be safely recycled.

[0137] It should be noted that in some embodiments of the present application, the scavenger can also update the state of the second variable of each first thread to prove that there is a scavenger working. Specifically, before determining the m first threads according to the n first variables and the m third time stamps local to the m first threads, the second operation can further include: updating the state of the n second variables local to the n first threads to a fourth state, which can be updated by CAS, the fourth state indicating that the second thread is in a state of waiting for the reader thread to leave the grace period, one first thread corresponding to one second variable.

[0138] To facilitate understanding of the above process, the following will be described in the Figure 2 Based on the corresponding embodiments, the process of the scavenger waiting for all the readers corresponding to the deployment of the GDump module to leave the grace period (i.e., GDump_syncrhonize) will be described in a specific example, please refer to Figure 8 , Figure 8 A flowchart of a process of the scavenger waiting for all the readers corresponding to the deployment of the GDump module to leave the grace period provided by the embodiments of the present application can specifically include the following steps:

[0139] 801, traverse all threads corresponding to the scavenger, and determine whether all threads are traversed, if yes, execute step 808, if not, execute step 802.

[0140] Firstly, the scavenger will traverse all threads (such as the n first threads described above) corresponding to the scavenger, and determine whether all threads are traversed, if yes, execute step 808, if not, execute step 802. It should be noted that all threads corresponding to the scavenger can not be in the read critical region state at the current time, so they are temporarily called threads.

[0141] 802, read the state variable of the thread to the I-state local to the scavenger, record the time stamp local to the thread to the I-ts local to the scavenger, and execute a hardware memory barrier.

[0142] Then, read the state variable of the current thread to the I-state local to the scavenger, record the time stamp local to the current thread to the I-ts local to the scavenger, and execute a hardware memory barrier (the scavenger considers that it is not on the performance critical path, so the hardware memory barrier is not critical to the performance).

[0143] As an example, the time stamp recorded to the scavenger local can be recorded as Tx.I-ts, Tx being the identification of the thread, for example, the time stamp of the recorded thread T1 can be recorded as T1.I-ts, the time stamp of the recorded thread T2 can be recorded as T2.I-ts, and so on.

[0144] 803, Try to replace I-state by CAS to mark that there is a recycler now, and determine whether the CAS succeeds or not, if yes, go to step 806, if no, go to step 804.

[0145] Try to replace I-state by CAS to update the state variable in the current thread to I-state | 0b10, which means that there is a recycler now. And determine whether the CAS succeeds or not, if yes, go to step 806, if no, go to step 804.

[0146] 804, Save the new state variable in the thread to I-state, read the new timestamp ts in the thread, and execute the hardware memory barrier.

[0147] Save the new state variable in the thread to I-state, and read the new timestamp ts in the thread, then execute the hardware memory barrier.

[0148] 805, Determine whether the new timestamp ts in the thread is greater than I-ts, if yes, go to step 801, if no, go to step 803.

[0149] Determine whether the new timestamp ts in the thread is greater than I-ts, if yes, go to step 801, if no, go to step 803. Here, the main reason is that if the CAS fails, it means that the current thread may have left the read critical section and entered a new read critical section again. If this is the case, it will update the timestamp and indicate that the previous read critical section has ended, and there is no need to wait later.

[0150] 806, Determine whether there is a reader according to I-state, if yes, go to step 807, if no, go to step 801.

[0151] Determine whether there is a reader according to the state read out (l_state & 0b01), if yes, go to step 807, if no, go to step 801.

[0152] 807, Add the thread to the reader waiting list, and go back to step 801.

[0153] Add the current thread to the reader waiting list, and jump to step 801.

[0154] 808, Traverse the reader waiting list, and determine whether it is traversed, if yes, go to step 811, if no, go to step 809.

[0155] Traverse the next reader in the reader waiting list, determine whether the traversal is completed, if yes, execute step 811, if no, execute step 809.

[0156] 809, determine whether the I-ts stored locally is less than the current timestamp ts of the reader, if yes, return to step 808, if no, execute step 810.

[0157] Further determine whether the I-ts stored locally by the reclaimer is less than the current timestamp ts of the reader, if yes, return to step 808, if no, execute step 810.

[0158] 810, wait for the I-ts stored locally until it is less than the current timestamp ts of the reader, and return to step 808.

[0159] Wait for the I-ts stored locally until it is less than the current timestamp ts of the reader (representing that the thread has been updated), and return to step 808.

[0160] 811, complete the waiting, and reclaim the memory.

[0161] Complete the waiting, and reclaim the memory correctly.

[0162] In summary, when the high bit of the state variable is 1, the local timestamp needs to be updated by the current thread, and the time when the local timestamp is updated by the current thread includes: 1) the high bit of the state variable is marked by the reclaimer during the execution of the read critical section by the current thread, then the local timestamp is updated by the current thread when the read critical section is executed; 2) the high bit of the state variable has been marked by the reclaimer when the current thread enters the read critical section, then the local timestamp is updated by the current thread when the read critical section is entered.

[0163] It should be noted here that during the execution of the read critical section by the current thread, if different reclaimers come or the same reclaimer comes multiple times, the current thread can only update the local timestamp once.

[0164] The data processing method provided by the embodiment of the application can be applied to all concurrent scenes, and is used to replace the existing RCU or directly use the GDump module for synchronization, so as to improve the concurrent performance of software. Specifically, the embodiment of the application can be used in a processor system with multiple physical cores, and is best used on a processor architecture using a weak memory model. In the operating system kernel such as Linux running on these processors, RCU has been widely used. The user state implementation LibURCU is also used by various open source software. The GDump module can be directly used in these software to replace RCU.

[0165] It should be noted that, in addition to the above scenarios, the embodiments of the present application can also be applied to other scenarios. For example, when the hardware memory barrier only needs to play a role in very rare cases, and in most cases there is no need to add it, and the hardware memory barrier causes a large performance overhead due to the memory access mode, a variant of the embodiment of the present application can be used to avoid using the hardware memory barrier. For example, this mechanism is used in the Read Log Update (RLU) mechanism to avoid entering the hardware memory barrier of the read critical section, and this mechanism is used in the read-write lock to avoid entering the hardware memory barrier of the read critical section. Among them, RLU is a variant mechanism of RCU.

[0166] The embodiments of the present application are primarily used in computer software to implement concurrent lock-free data structures, and are used by computer software (such as operating system kernels, databases, and even applications). Lock-free data structures that can be implemented using this mechanism include linked lists, Radix trees, red-black trees, and red-black tree hash tables.

[0167] In order to have a more intuitive understanding of the beneficial effects brought about by the embodiments of the present application, the technical effects brought about by the embodiments of the present application are further compared below.

[0168] As an example, this application is implemented in C language and used for microbenchmark testing. The implementation provides the three interfaces GDump_enter, GDump_exit, and GDump_syncrhonize described above. This microbenchmark is used to compare the performance improvement of GDump in this application with the existing widely used URCU-bp (an implementation in LibURCU that does not require application modification). The microbenchmark test consists of two parts: the first part is a read critical section for accessing a single shared data; the second part is a read critical section for traversing a linked list with 512 elements. The microbenchmark test includes whether to create a writer thread (on different non-uniform memory access architecture (NUMA) nodes). For the first part of the test, the writer will continuously modify the shared data; for the second part of the test, the writer will randomly select an element in the 512-element linked list, delete it, and then add it back. The writer does not involve data recycling. The microbenchmark test will measure the time it takes for the reader to complete a certain number of read critical sections and calculate the throughput of the corresponding mechanism based on this.

[0169] Figure 9 The test results of the first part of the test are shown. Figure 9 The vertical axis is the universal throughput (compared to URCU). Figure 9The middle horizontal axis w / o Writer represents no writer. At this time, the throughput of GDump is 80% higher than that of URCU, which is mainly benefited from the help of avoiding memory barriers to local out-of-order execution. When there is a writer, the performance benefit of eliminating the hardware memory barrier is further improved, and at this time, the throughput of GDump is 105% higher than that of URCU.

[0170] Figure 10 The test results of the second part of the test are shown, and since the read critical section needs to traverse a linked list of 512 elements, the read critical section is significantly longer than the test of the first part. In this test, whether there is a writer has little effect on performance. GDump is 50% higher than URCU in stable throughput.

[0171] To further verify the effect of the embodiment of the application, the application also provides an application diagram of implementing a lock-free data structure in the Hongmeng kernel by using GDump, and details can be referred to Figure 11 , wherein the lock-free data structure includes a Radix tree, a red-black tree, a hash table, a dlist linked list, and the like. The way of implementing the lock-free data structure by using the synchronization mechanism of the embodiment of the application is consistent with the background introduction: the reader needs to call the interface of entering / leaving the read critical section to mark the range of the read critical section. The writer can directly complete the update of data by using a single-atomic storage operation. The recycler needs to call the interface provided by the application to block until all readers leave the grace period, and then the target node deleted / updated before can be recycled. Figure 11 The relationship diagram of the application program using GDump and GDump is shown. The application program will directly use the interface of the provided lock-free data structure (such as Figure 11 radix_tree_read in the background), and the interface of the corresponding data structure will call the GDump interface (such as GDump_enter entering the read critical section). These lock-free data structures are widely used in the system service sysmgr of the Hongmeng kernel and the Hongmeng file system. In addition to the Hongmeng kernel, the lock-free data interface can also be widely used by other application programs, such as a database.

[0172] On the basis of the above-mentioned embodiments, in order to better implement the above-mentioned scheme of the embodiment of the application, the related device for implementing the above-mentioned scheme is further provided below. Details can be referred to Figure 12 , Figure 12A structural diagram of a computer device is provided in the embodiments of the present application. The computer device 1200 runs a first thread and a second thread. The first thread belongs to a reader thread, and the second thread belongs to a reclaimer thread. The computer device 1200 includes a calling module 1201, an updating module 1202, and an executing module 1203. The calling module 1201 is configured to call a first interface for entering a read critical section, so that the first thread enters the read critical section. The updating module 1202 is configured to update a first variable local to the first thread from a first state to a second state, so that the second thread determines an ending moment of a grace period based on the first variable. The first variable is used to represent whether the first thread enters the read critical section. The first state indicates that the first thread does not enter the read critical section. The second state indicates that the first thread has entered the read critical section. The executing module 1203 is configured to execute the read critical section in a case where a second variable local to the first thread is in a third state. The second variable is used to represent whether the second thread is in a state of waiting for a reader thread to leave the grace period. The third state indicates that the second thread is not in the state of waiting for the reader thread to leave the grace period.

[0173] In a possible design, the executing module 1203 is further configured to: in a case where the second variable is in a fourth state, execute a first hardware memory barrier. The fourth state indicates that the second thread is in the state of waiting for the reader thread to leave the grace period; and then execute the read critical section.

[0174] In a possible design, the updating module 1202 is further configured to: before the executing module 1203 executes the first hardware memory barrier, update a time stamp local to the first thread to a first time stamp.

[0175] In a possible design, the calling module 1201 is further configured to: after the executing module 1203 executes the read critical section, call a second interface for exiting the read critical section, so that the first thread exits the read critical section; and the executing module 1203 is further configured to execute a release hardware memory barrier.

[0176] In a possible design, after the calling module 1201 calls the second interface for exiting the read critical section, so that the first thread exits the read critical section, the updating module 1202 is further configured to: update the first variable from the second state to the first state; and in a case where the second variable is not in the third state, update the second variable to the third state.

[0177] In a possible design, the executing module 1203 is further configured to: after executing the release hardware memory barrier, exit the read critical section in a case where the second variable is updated to the third state.

[0178] In a possible design, the execution module 1203 is further configured to: after executing the release hardware memory barrier, execute a second hardware memory barrier in a case where the third state is not met before the second variable is updated; and then exit the read critical section.

[0179] In a possible design, the update module 1202 is further configured to: before the execution module 1203 executes the second hardware memory barrier, update the time stamp local to the first thread to a second time stamp.

[0180] In a possible design, a first update time is later than a second update time. The first update time is a time when the time stamp local to the first thread is updated to the second time stamp, and the second update time is a time when the second variable is updated to the third state in a case where the third state is not met.

[0181] It should be noted that the information interaction and execution process between the modules / units in the computer device 1200 are the same as the above-described Figures 4 to 6 The corresponding method embodiments are based on the same concept. For details, refer to the descriptions of the method embodiments in the foregoing description of the present application, which will not be repeated here.

[0182] The present application also provides a computer device, which is specifically described in the following Figure 13 , Figure 13 Another structural diagram of a computer device provided by the present application is shown in FIG. 13. The computer device 1300 runs n (n≥2) first threads and second threads. The first threads belong to reader threads, and the second threads belong to recycler threads. The computer device 1300 includes an acquisition module 1301, a determination module 1302, and a recycling module 1303. The acquisition module 1301 is configured to acquire n first variables local to the n first threads and n third time stamps local to the n first threads. One first thread corresponds to one first variable and one third time stamp. The third time stamp is a time stamp local to the first thread at an acquisition time. The first variable is used to represent whether the first thread enters a read critical section. The determination module 1302 is configured to determine m first threads and m third time stamps local to the m first threads according to the n first variables. The current states of the m first variables of the m first threads are all the second state. The second state indicates that the first thread has entered the read critical section. m≥1. The recycling module 1303 is configured to recycle memory corresponding to a grace period in a case where a fourth time stamp local to a target first thread at a current time is greater than the third time stamp of the target first thread. The target first thread is any one of the m first threads.

[0183] In one possible design, the computer device 1300 also includes an update module 1304, which is used to update the states of the n second variables local to the n first threads to a fourth state before the determination module 1302 determines the m first threads and the m third timestamps local to the m first threads based on the n first variables. The fourth state indicates that the second thread is in a state of waiting for the reader thread to leave the grace period, and one first thread corresponds to one second variable.

[0184] In a possible design, the update module 1304 is specifically configured to update the states of the n second variables local to the n first threads to a fourth state through CAS.

[0185] In one possible design, the computer device 1300 further includes an execution module 1305, which is configured to execute a third hardware memory barrier after the acquisition module 1301 acquires the n first variables local to the n first threads and the n third timestamps local to the n first threads.

[0186] It should be noted that the information interaction, execution process, etc. between the modules / units in the computer device 1300 are the same as those in the above-mentioned Figure 7 、 Figure 8 The corresponding method embodiments are based on the same concept. For specific contents, please refer to the description in the method embodiments shown above in this application, which will not be repeated here.

[0187] Next, we will introduce a computer device provided by an embodiment of the present application. Figure 14 , Figure 14 A schematic diagram of a computer device provided in an embodiment of the present application is provided. The computer device 1400 may be deployed with Figure 12 The modules described in the corresponding embodiment are used to implement Figure 12 Corresponding to the functions of the computer device 1200 in the embodiment, the computer device 1400 may also be deployed with Figure 13 The modules described in the corresponding embodiment are used to implement Figure 13Corresponding to the functions of the computer device 1300 in the embodiments, the specific embodiments of the present application are not limited thereto. Specifically, the computer device 1400 is implemented by one or more servers, and the computer device 1400 can be significantly different due to different configurations or performances, and can include one or more central processing units (CPU) 1422 and a memory 1432, one or more storage media 1430 (such as one or more mass storage devices) for storing application programs 1442 or data 1444. Among them, the memory 1432 and the storage medium 1430 can be temporary storage or persistent storage. The programs stored in the storage medium 1430 can include one or more modules (not shown in the figure), and each module can include a series of instruction operations in the computer device 1400. Further, the central processing unit 1422 can be configured to communicate with the storage medium 1430 and execute a series of instruction operations in the storage medium 1430 on the computer device 1400.

[0188] The computer device 1400 can also include one or more power supplies 1426, one or more wired or wireless network interfaces 1450, one or more input / output interfaces 1458, and / or one or more operating systems 1441, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0189] In the embodiments of the present application, the central processing unit 1422 is used to execute the steps in the above method embodiments. The specific implementation of the central processing unit 1422 executing each step is based on the same concept as the above method embodiments in the present application, and the technical effects brought by it are the same as the above embodiments in the present application. For details, please refer to the description of the method embodiments in the foregoing description of the present application. Here, it will not be repeated.

[0190] In addition, it should be noted that the apparatus embodiments described above are only schematic, and the units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, i.e. they can be located in one place, or distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the present embodiment. In addition, the connection relationship between the modules in the apparatus embodiment provided by the present application indicates that there is a communication connection between them. Specifically, it can be implemented as one or more communication buses or signal lines.

[0191] Those skilled in the art can clearly understand that the application can be implemented by means of software plus necessary universal hardware, and of course can also be implemented by means of dedicated hardware including special integrated circuit, special CPU, special memory, special components, etc. Generally, any function completed by computer program can be easily implemented by corresponding hardware, and the specific hardware structure for implementing the same function can also be various, such as analog circuit, digital circuit or special circuit, etc. However, for the application, software program implementation is a better embodiment. Based on such understanding, the technical solutions of the application can be embodied in the form of software product, or combination of software product and hardware product, and the computer software product is stored in readable storage medium, such as computer floppy disk, U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc., including a plurality of instructions for making a computer device (which can be personal computer, training device or network device, etc.) execute the method described in various embodiments of the application.

[0192] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product.

[0193] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable devices. The computer instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, the computer instructions can be transmitted from one website, computer, training device or data center to another website, computer, training device or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer readable storage medium can be any available medium that can be stored by the computer or the data storage device such as training device, data center, etc. integrated with one or more available media sets. The available medium can be magnetic medium (such as floppy disk, hard disk, magnetic tape), optical medium (such as DVD), or semiconductor medium (such as solid state disk (SSD)), etc.

Claims

1. A method of data processing, characterized by, The method is applied to a computer device on which a first thread and a second thread run, the first thread belongs to a reader thread, and the second thread belongs to a recycler thread, and the method comprises the following steps of: running, by the first thread, a first code segment to perform the following first operation: calling a first interface for entering a read critical section to enter the read critical section; updating a first variable local to the first thread from a first state to a second state, so that the second thread determines an end time of a grace period based on the first variable, the first variable being used to represent whether the first thread enters the read critical section, the first state indicating that the first thread does not enter the read critical section, and the second state indicating that the first thread has entered the read critical section; in a case where a second variable local to the first thread is in a third state, performing the read critical section, the second variable being used to represent whether the second thread is in a state of waiting for a reader thread to leave the grace period, and the third state indicating that the second thread is not in the state of waiting for the reader thread to leave the grace period.

2. The method of claim 1, wherein, The first operation further comprises the following steps of: in a case where the second variable is in a fourth state, performing a first hardware memory barrier, the fourth state indicating that the second thread is in the state of waiting for the reader thread to leave the grace period; performing the read critical section.

3. The method according to claim 2, characterized in that The first operation further comprises the following steps of: before performing the first hardware memory barrier, updating a timestamp local to the first thread to a first timestamp.

4. The method according to any one of claims 1-3, characterized in that, The first operation further comprises the following steps of: after performing the read critical section, calling a second interface for exiting the read critical section to exit the read critical section; performing a release hardware memory barrier.

5. The method of claim 4, wherein, After the calling of the second interface for exiting the read critical section to exit the read critical section, the first operation further comprises the following steps of: updating the first variable from the second state to the first state; in a case where the second variable is not in the third state, updating the second variable to the third state.

6. The method of claim 5, wherein, After the performing of the release hardware memory barrier, the first operation further comprises the following steps of: in a case where the second variable is updated to the third state, exiting the read critical section.

7. The method according to any one of claims 5-6, characterized in that, After the performing of the release hardware memory barrier, the first operation further comprises the following steps of: in a case where the second variable is not updated to the third state, performing a second hardware memory barrier; exiting the read critical section.

8. The method of claim 7, wherein, Before the performing of the second hardware memory barrier, the first operation further comprises the following steps of: updating the timestamp local to the first thread to a second timestamp.

9. The method of claim 8, wherein: the first update time is later than the second update time; the first update time is a time when the timestamp local to the first thread is updated to the second timestamp; and the second update time is a time when, in a case where the second variable is not in the third state, the second variable is updated to the third state.

10. A method of data processing, characterized by, The method is applied to a computer device on which n first threads and a second thread run, the first threads belong to reader threads, and the second thread belongs to a recycler thread, and the method comprises the following steps of: run a second code segment by the second thread to perform a second operation: obtain n first variables local to the n first threads and n third time stamps local to the n first threads, one first thread corresponding to one first variable and one third time stamp, the third time stamp being a time stamp local to the first thread at an acquisition time, the first variable being used to represent whether the first thread enters a read critical section; determine m first threads and m third time stamps local to the m first threads according to the n first variables, current states of m first variables of the m first threads all being a second state, the second state representing that the first thread has entered the read critical section, m≥1; in a case where a fourth time stamp local to a target first thread at a current time is greater than the third time stamp of the target first thread, recycle memory corresponding to the grace period, the target first thread being any one of the m first threads.

11. The method of claim 10, wherein, Before the determining m first threads and m third time stamps local to the m first threads according to the n first variables, the second operation further includes: update states of n second variables local to the n first threads to a fourth state, the fourth state representing that the second thread is in a state of waiting for a reader thread to leave the grace period, one first thread corresponding to one second variable.

12. The method of claim 11, wherein, The updating the states of the n second variables local to the n first threads to the fourth state includes: updating the states of the n second variables local to the n first threads to the fourth state by an atomic compare-and-swap operation (CAS).

13. The method according to any one of claims 10-12, characterized in that, After the obtaining the n first variables local to the n first threads and the n third time stamps local to the n first threads, the second operation further includes: performing a third hardware memory barrier.

14. A computer device, comprising: The computer device runs a first thread and a second thread, the first thread belonging to a reader thread, and the second thread belonging to a recycler thread, and the computer device includes: a calling module configured to call a first interface of entering a read critical section, so as to make the first thread enter the read critical section; an updating module configured to update a first variable local to the first thread from a first state to a second state, so as to make the second thread determine an end time of a grace period based on the first variable, the first variable being used to represent whether the first thread enters the read critical section, the first state representing that the first thread does not enter the read critical section, and the second state representing that the first thread has entered the read critical section; an executing module configured to, in a case where a second variable local to the first thread is in a third state, execute the read critical section, the second variable being used to represent whether the second thread is in a state of waiting for a reader thread to leave the grace period, and the third state representing that the second thread is not in the state of waiting for the reader thread to leave the grace period.

15. The apparatus of claim 14, wherein, The executing module is further configured to: in a case where the second variable is in a fourth state, perform a first hardware memory barrier, the fourth state representing that the second thread is in the state of waiting for the reader thread to leave the grace period; and execute the read critical section.

16. The apparatus of claim 15, wherein, The updating module is further configured to: update the timestamp local to the first thread as a first timestamp before the execution module executes the first hardware memory barrier.

17. The device of any one of claims 14-16, wherein, The calling module is further configured to call a second interface for exiting the read critical section to cause the first thread to exit the read critical section after the execution module executes the read critical section. The execution module is further configured to execute a release hardware memory barrier.

18. The apparatus of claim 17, wherein, The updating module is further configured to: update the first variable from the second state to the first state; update the second variable to the third state if the second variable is not in the third state.

19. The apparatus of claim 18, wherein, The execution module is further configured to: exit the read critical section if the second variable is not in the third state before the second variable is updated.

20. The apparatus of any one of claims 18-19, wherein, The execution module is further configured to: execute a second hardware memory barrier if the second variable is not in the third state before the second variable is updated after the execution of the release hardware memory barrier; exit the read critical section.

21. The apparatus of claim 20, wherein, The updating module is further configured to: update the timestamp local to the first thread as a second timestamp before the execution module executes the second hardware memory barrier.

22. The device of claim 21, wherein, the first update time is later than the second update time; the first update time is when the timestamp local to the first thread is updated as the second timestamp; the second update time is when the second variable is updated to the third state if the second variable is not in the third state.

23. A computer device, comprising: The computer device runs n first threads and a second thread, the first threads belong to reader threads, and the second thread belongs to a recycler thread, and the computer device comprises: an acquisition module configured to acquire n first variables local to the n first threads and n third timestamps local to the n first threads, one first thread corresponding to one first variable and one third timestamp, the third timestamp being a timestamp local to the first thread at an acquisition time, and the first variable being used to represent whether the first thread enters a read critical section; a determination module configured to determine m first threads and m third timestamps local to the m first threads according to the n first variables, the m first threads having m first variables in a second state, the second state indicating that the first thread has entered the read critical section, and m being greater than or equal to 1; a recycling module configured to recycle memory corresponding to a grace period if a fourth timestamp local to a target first thread at a current time is greater than the third timestamp of the target first thread, the target first thread being any one of the m first threads.

24. The apparatus of claim 23, wherein, The computer device further comprises an updating module. The updating module is configured to update states of n second variables local to the n first threads to a fourth state before the determining module determines m first threads according to the n first variables and m third timestamps local to the m first threads, the fourth state indicating that the second threads are in a state of waiting for a reader thread to leave the grace period, one first thread corresponding to one second variable.

25. The apparatus of claim 24, wherein, The updating module is specifically configured to: update the states of the n second variables local to the n first threads to the fourth state through an atomic compare-and-swap (CAS) operation.

26. The apparatus of any one of claims 23-25, wherein, The computer device further includes an executing module. The executing module is configured to execute a third hardware memory barrier after the acquiring module acquires the n first variables local to the n first threads and the n third timestamps local to the n first threads. 27.A computer device, comprising a processor and a memory, the processor being coupled to the memory, and characterized in that, the memory is configured to store a program; the processor is configured to execute the program in the memory, so that the tool system executes the method according to any one of claims 1-13.

28. A computer storage medium, comprising, The computer readable instructions are stored, and the computer readable instructions, when executed by a processor, implement the method according to any one of claims 1-13.

29. A computer program product, characterised in that, The computer program product includes computer readable instructions, and when the computer readable instructions are executed by a processor, the method according to any one of claims 1-13 is implemented.

30. A chip comprising a processor and a data interface, characterized in that The processor reads the instructions stored on the memory through the data interface and executes the method according to any one of claims 1-13.

Images