Apparatus and method for distributed memory transactions

Abstract

A data processing apparatus (110) for managing distributed memory transactions on a plurality of objects stored in a plurality of memory nodes (120a to 120c) is disclosed. The distributed memory transaction comprises an execution stage and a subsequent verification and submission stage, and the plurality of objects comprise one or more read set objects and / or one or more write set objects. In the verification and commit phase, the data processing means (110) is configured to perform a processing phase: (a) lock and verify the one or more write set objects; (b) verifying the one or more read set objects; (c) submitting a change and unlocking the one or more write set objects. The data processing means (110) are configured to perform the processing phases (a) and (b) and / or the processing phases (b) and (c) of the verification and commit phases substantially in parallel.

Description

Technical Field

[0001] The present disclosure relates to information processing technology, and more particularly to a device and method for distributed memory transactions. Background Art

[0002] Distributed memory-centric transactions are memory access transactions that span multiple physical or virtual memory nodes in a network of memory nodes. One of the main challenges of distributed memory transactions (which typically involve accessing and / or manipulating memory objects on multiple different memory nodes) is to always maintain a consistent view of memory. Managing such transactions is complex because it requires coordinating the steps executed on different memory nodes in order to maintain the atomicity (all-or-nothing nature) of the transaction under concurrent conditions while maintaining memory consistency. Typically, no transaction is allowed to operate on partial results of other transactions, and each transaction starts with a consistent view of memory that is the result of the previous transactions that completed successfully.

[0003] Optimistic approaches to distributed memory transactions achieve high performance in low-data-contention environments by using lock-free data structures instead of computationally expensive locks. Optimistic approaches typically rely on an execute phase, in which the execute phase performs the required read and write memory operations on isolated work areas without taking any locks, and a commit and verify phase, in which the execute phase verifies that the view it held during the execute phase is still valid (possibly locking write-set objects for a short period of time), and based on the results of the verification, makes the required changes in place (i.e., at the actual location in memory), and then unlocks all objects it previously locked. Summary of the Invention

[0004] The purpose is to provide improved apparatus and methods for distributed memory transactions.

[0005] The above and other objects are achieved by the subject matter claimed in the independent claims. Other implementations are apparent from the dependent claims, the description and the drawings.

[0006] According to a first aspect, there is provided an apparatus (also referred to herein as a coordinator) for managing distributed memory transactions on a plurality of objects stored in a plurality of memory nodes of a memory node network. The distributed memory transactions comprise an execution phase and a subsequent validation and commit phase, wherein the plurality of objects comprise one or more read-set objects and / or one or more write-set objects. During the validation and commit phase, the apparatus is configured to perform the following processing phases:

[0007] (a) locking and validating the one or more writeset objects;

[0008] (b) verifying the one or more read set objects;

[0009] (c) Committing the changes and unlocking the one or more writeset objects.

[0010] The apparatus is configured to perform the processing stages (a) and (b) and / or the processing stages (b) and (c) of the validation and commit phase substantially in parallel. Thus, an improved apparatus for managing distributed memory transactions in an accelerated and more efficient manner is provided.

[0011] In another possible implementation, during the execution phase, the device is further used to: obtain the atomic version number of each of the multiple objects to verify the one or more write set objects and / or the one or more read set objects in the verification and submission phase, for example, by comparing the object version number obtained in the execution phase with the object version number obtained in the verification and submission phase.

[0012] In another possible implementation, the device includes or is implemented as, for example, a network interface card (NIC) of a server, a memory processor, or a hardware accelerator.

[0013] In another possible implementation, the device is a memory node among the plurality of memory nodes. In other words, in one implementation, the device, ie, the coordinator itself, may be one of the memory nodes involved in the distributed memory transaction.

[0014] In another possible implementation, the apparatus is configured to perform processing stages (a) and (b) of the verification and submission stage substantially in parallel before processing stage (c), wherein the one or more read set objects include a first read set object stored on a first memory node among the plurality of memory nodes and a second read set object stored on a second memory node among the plurality of memory nodes, and wherein the data processing apparatus is configured to trigger the first memory node and the second memory node to lock the first read set object and the second read set object using a shared lock shared by the first memory node and the second memory node. It should be understood that in other implementations, the shared lock may be shared by one or more other memory nodes in addition to the first memory node and the second memory node.

[0015] In another possible implementation, the apparatus is configured to perform processing stages (b) and (c) of the verification and submission stages substantially in parallel after stage (a), wherein, in processing stage (b), the apparatus is configured to trigger one or more memory nodes of the plurality of memory nodes storing the one or more write set objects to generate a backup copy of the corresponding write set object.

[0016] In another possible implementation, the device is used to trigger one or more memory nodes among the multiple memory nodes storing the one or more write set objects to perform a rollback based on the backup copy of the corresponding write set object in response to receiving information from one or more memory nodes among the multiple memory nodes that the verification and commit phase has failed.

[0017] In another possible implementation, the apparatus is configured to perform processing stages (a), (b), and (c) of the verification and commit stages substantially in parallel, wherein the one or more read set objects include a first read set object stored on a first memory node among the plurality of memory nodes and a second read set object stored on a second memory node among the plurality of memory nodes, and wherein the data processing apparatus is configured to trigger the first memory node and the second memory node to lock the first read set object and the second read set object using a shared lock shared by the first memory node and the second memory node. It should be understood that in other implementations, the shared lock may be shared by one or more other memory nodes in addition to the first memory node and the second memory node.

[0018] In another possible implementation, the device is used to execute processing stages (a) and (b) of the verification and submission stage substantially in parallel in a first selectable operating mode, execute processing stages (b) and (c) of the verification and submission stage substantially in parallel in a second selectable operating mode, and execute processing stages (a), (b) and (c) of the verification and submission stage substantially in parallel in a third selectable operating mode, wherein the data processing device is used to select the first selectable operating mode, the second selectable operating mode or the third selectable operating mode for managing the distributed memory transaction.

[0019] In another possible implementation, the device is used to obtain statistical data of multiple distributed memory transactions executed using a previously selected operating mode, and to select the first selectable operating mode, the second selectable operating mode, or the third selectable operating mode for managing the distributed memory transactions based on the statistical data.

[0020] In another possible implementation, for example, the statistical data acquired (eg, collected) by the apparatus includes data indicating a global contention level and / or data indicating an object contention level.

[0021] According to a second aspect, a data processing system is provided, wherein the data processing system comprises a plurality of memory nodes and an apparatus according to the first aspect for managing distributed memory transactions on a plurality of objects stored in the plurality of memory nodes.

[0022] According to a third aspect, a method for managing distributed memory transactions on multiple objects stored in multiple memory nodes of a memory node network is provided, wherein the distributed memory transaction includes an execution phase and a subsequent verification and commit phase, wherein the multiple objects include one or more read-set objects and / or one or more write-set objects. During the verification and commit phase, the method includes the following processing phases:

[0023] (a) locking and validating the one or more writeset objects;

[0024] (b) verifying the one or more read set objects;

[0025] (c) committing changes and unlocking the one or more writeset objects,

[0026] Wherein, the processing stages (a) and (b) and / or the processing stages (b) and (c) of the verification and submission stage are substantially performed in parallel.

[0027] The method according to the third aspect of the present disclosure can be performed by the apparatus according to the first aspect of the present disclosure. Therefore, the other features of the method according to the third aspect of the present disclosure are directly derived from the functions of the apparatus according to the first aspect of the present disclosure and the different implementations described above and below.

[0028] According to a fourth aspect, a computer program product is provided, comprising a computer-readable storage medium for storing program code, which, when executed by a computer or a processor, causes the computer or processor to perform the method according to the third aspect.

[0029] One or more embodiments will be described in detail in the accompanying drawings and the following description. Other features, objects, and advantages will be apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The following describes the embodiments of the present disclosure in detail with reference to the accompanying drawings. In the accompanying drawings:

[0031] Figure 1 A schematic diagram illustrating a memory node network and a coordinator according to an embodiment for managing distributed memory transactions in the memory node network is shown;

[0032] Figure 2 A diagram illustrating the interaction between a conventional coordinator and multiple memory nodes for distributed memory transactions;

[0033] Figure 3 A diagram illustrating interaction between a coordinator and a plurality of memory nodes according to a first embodiment for distributed memory transactions;

[0034] Figure 4 A diagram illustrating interaction between a coordinator and a plurality of memory nodes according to a second embodiment for distributed memory transactions;

[0035] Figure 5 A schematic diagram illustrating an operation of a memory node on a temporary storage area according to an embodiment is shown;

[0036] Figure 6 A diagram illustrating interaction between a coordinator and a plurality of memory nodes according to a third embodiment for distributed memory transactions;

[0037] Figure 7 A diagram illustrating interaction between a coordinator and a plurality of memory nodes according to a fourth embodiment for distributed memory transactions;

[0038] Figure 8 A flowchart of selecting a distributed memory transaction mode by a coordinator according to an embodiment is shown.

[0039] In the following, identical reference numerals refer to identical or at least functionally equivalent features. DETAILED DESCRIPTION

[0040] In the following description, reference is made to the accompanying drawings, which form part of the present disclosure and illustrate, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It should be understood that the embodiments of the present disclosure may be used in other aspects and may include structural or logical changes not described in the drawings. Therefore, the following detailed description should not be understood in a restrictive sense, and the scope of the present disclosure is defined by the appended claims.

[0041] For example, it should be understood that the disclosure related to describing a method may also apply to a corresponding device or system for performing the method, and vice versa. For example, if one or more specific method steps are described, the corresponding device may include one or more units (e.g., functional units) to perform the one or more method steps described (e.g., one unit performs one or more steps, or multiple units perform one or more of the multiple steps respectively), even if the one or more units are not explicitly described or illustrated in the drawings. On the other hand, for example, if a specific device is described based on one or more units (e.g., functional units), the corresponding method may include a step to perform the function of the one or more units (e.g., one step performs the function of the one or more units, or multiple steps perform the function of one or more of the multiple units respectively), even if the one or more steps are not explicitly described or illustrated in the drawings. In addition, it should be understood that, unless otherwise stated, the features of the various exemplary embodiments and / or aspects described herein may be combined with each other.

[0042] Figure 1A schematic diagram of a data processing system 100 including multiple memory nodes 120a to 120c and an apparatus 110 for managing distributed memory transactions using the multiple memory nodes 120a to 120c is shown according to an embodiment. The apparatus 110 (also referred to herein as the coordinator 110) can be implemented as, for example, a cloud server, a network interface card (NIC) of a cloud server, a memory processor, or a hardware accelerator. In another embodiment, the coordinator 110 can be one of the multiple memory nodes 120a to 120c of the data processing system 100.

[0043] As used herein, a memory transaction comprises one or more operations on (possibly) multiple memory objects within a data structure, wherein the operations should ensure memory consistency, i.e., either all operations complete successfully or none of them complete. For example, a memory transaction may comprise inserting data into a binary tree, which involves manipulating the contents of (possibly) several nodes in the tree. As another example, a memory transaction may comprise inserting data into a doubly linked list, which involves changing the pointers of the previous and next objects.

[0044] As used herein, a distributed memory transaction is a transaction that accesses memory residing on multiple memory nodes (e.g. Figure 1 Memory transactions for memory objects on multiple memory nodes 120a to 120c are shown. For example, memory nodes 120a to 120c can be physical or virtual servers or different processes on the same server.

[0045] like Figure 1 As shown, the coordinator 110 may include a processing circuit 111, a communication interface 113 and / or a memory 115. The processing circuit 111 may be implemented in hardware and / or software and may include a digital circuit, or both an analog circuit and a digital circuit. The digital circuit may include components such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP) or a general-purpose processor. The communication interface 113 may be used to communicate with the memory nodes 120a to 120c via a wired and / or wireless connection. The memory 115 of the coordinator 110 may be used to store executable program code, which, when executed by the processing circuit 111, enables the coordinator 110 to perform the functions and methods described herein.

[0046] Figure 2A diagram illustrating the interaction between a conventional coordinator and multiple memory nodes for an exemplary distributed memory transaction scheme 200 is shown. Figure 2 In the exemplary distributed memory transaction scheme 200 shown, three memory objects are part of the transaction, namely, objects a and b residing in memory nodes N1 and N2, respectively, and forming a read set (i.e., objects a and b are only read during the transaction and their values ​​are not changed), and object x residing in memory node N3 and forming a write set (i.e., the value of object x is changed during the transaction). Figure 2 The conventional distributed memory transaction scheme 200 shown, disclosed in more detail in Dragojevic, A., et al., “FaRM: Fast Remote Memory,” in Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI’14), April 2-4, 2014, Seattle, WA, USA, is an optimistic concurrency control scheme divided into two main phases, namely, the execution phase and the commit and verify phase.

[0047] The execution phase of the transaction includes sub-step 1: all read set objects ( Figure 2 a, b in the example shown, residing in nodes N1, N2 respectively) and the values ​​of the writeset object (x, residing in node N3) are fetched to the central coordinator C; and Sub-step 2: Calculate the required changes to the writeset object (x).

[0048] During the commit and verify phase, the central coordinator C acquires a short-term lock for each write-set object and verifies the values ​​of both the read-set and write-set objects. Verification involves checking that the objects have not changed since they were accessed in the execute phase (e.g., using atomic updates to version numbers for each object, etc.). More specifically, the commit and verify phase consists of the following three sub-steps 3 to 5: In sub-step 3, the coordinator first locks and verifies the write-set objects; only if sub-step 3 completes successfully does the coordinator C verify the read-set objects in sub-step 4; and only if sub-steps 3 and 4 succeed does the coordinator C commit changes to the write-set objects and unlock them in sub-step 5. Only after the unlock occurs does the coordinator C now notify the calling application (the application that initiated the in-memory transaction) of the successful transaction completion. If any of sub-steps 3, 4, or 5 fails, the entire transaction is aborted, nothing is committed, and no changes are made in memory.

[0049] It should be understood that Figure 2 In the conventional distributed memory transaction solution 200 shown, three round trip times (RTTs) are required before the calling application is notified of a successful transaction, namely the round trip times in sub-steps 3, 4, and 5. In the case of slow network access, this may become a bottleneck for executing and submitting transactions.

[0050] As will be described in more detail below, Figure 1 The coordinator 110 shown is used to implement the distributed memory transaction scheme 300 according to different embodiments, thereby reducing Figure 2 Execution time of the traditional distributed memory transaction scheme 200 shown. An embodiment of the coordinator 110 disclosed herein improves the commit and verify phases of a distributed memory transaction. More specifically, in the verify and commit phase, the coordinator 110 is configured to perform the following processing phases: (a) locking and verifying one or more write set objects; (b) verifying one or more read set objects; and (c) committing changes and unlocking one or more write set objects. The coordinator 110 is configured to perform processing phases (a) and (b) and / or processing phases (b) and (c) of the verify and commit phase substantially in parallel. In an embodiment, in the execution phase, the coordinator 110 is further configured to: read an atomic version number of each of a plurality of objects to verify one or more write set objects and / or one or more read set objects in the verify and commit phase, for example, by comparing the object version number obtained in the execution phase with the object version number obtained in the verify and commit phase.

[0051] Figure 3 1 shows the interaction between the coordinator 110 and three memory nodes 120a to 120c as an example for implementing the distributed memory transaction solution 300 according to the first embodiment. As can be understood from the more detailed description below, Figure 3 The distributed memory transaction scheme 300 shown can be parallelized Figure 2 The conventional distributed memory transaction scheme 200 is shown to accelerate its commit phase by performing two sub-steps, in particular by managing lock, validation and commit operations in the manner described below. Figure 3 The exemplary scenario shown involves two memory nodes 120a, 120b having corresponding read set objects and one memory node 120c having a write set object. However, it should be understood that the embodiments disclosed herein can be applied to multiple memory nodes 120a-120c, including more than two memory nodes 120a, 120b having one or more read set objects and / or more than one memory node 120c having one or more write set objects.

[0052] from Figure 3 It can be seen that in this first embodiment, write set verification and locking (i.e. Figure 2 Sub-step 3) Verify the read set (i.e. Figure 2 Sub-step 4) is done in parallel. In other words, Figure 3 In the first embodiment shown, for each memory node 120a to 120c, write set verification and locking (i.e. Figure 2 Sub-step 3) and read set verification (i.e. Figure 2 Sub-step 4).

[0053] The device 110 (eg, the coordinator 110) may concurrently communicate with the three exemplary memory nodes 120a to 120c, instructing each of these memory nodes to lock and verify the memory objects it owns. Figure 3 In the exemplary scenario shown, controller 110 instructs first memory node 120a and second memory node 120b to perform the above operations on the read-set object, while controller 110 instructs third memory node 120c to lock and verify the write-set object. In embodiments, short lock cycles can be used during the commit phase with different lock semantics to support parallelization of read-set verification and write-set locking.

[0054] exist Figure 3 In the first embodiment shown, the first memory node 120a and the second memory node 120b are used (as instructed by the controller 110) to use shared locks on the corresponding read set objects they own, while the third memory node 120c is used to exclusively lock the write set objects it owns. It should be understood that sampling shared locks on read set objects supports parallelization. Figure 3 Sub-steps 3 and 4 of the verification and submission phases of the distributed memory transaction solution 300 are shown. This is because the shared locks adopted by the first memory node 120a and the second memory node 120b can ensure that the read set object will not be changed after the write set object lock is adopted. Figure 2 , which is achieved by waiting for the write-set lock to complete before starting the read-set verification. As mentioned above, in other embodiments, in addition to the first memory node 120a and the second memory node 120b, the shared lock can be shared by one or more other memory nodes.

[0055] exist Figure 3 In the first embodiment shown, after all verifications and locks are completed, the actual changes are committed to the corresponding memory in sub-step 5. It should be understood that Figure 2 Compared with the conventional distributed memory transaction solution 200 shown in FIG, the first embodiment provides a distributed memory transaction solution implemented by the controller 110 and the memory nodes 120a to 120c. Figure 3 The distributed memory transaction scheme 300 can reduce network round-trip time (RTT) during the validation and commit phases, thereby shortening the time it takes to commit a transaction. For one embodiment, where the distributed memory transaction scheme 300 is executed by the NIC of the controller 110 and / or the corresponding NIC of each memory node in the memory nodes 120a to 120c, synchronous message passing can be offloaded, latency for responses from the host CPU can be reduced, and core cycles can be saved.

[0056] Figure 4 The following diagram illustrates the interaction between an apparatus 110 (eg, controller 110) for executing a distributed memory transaction solution 300 and three memory nodes 120a to 120c as examples according to the second embodiment. It will be appreciated from the following more detailed description that: Figure 4 The distributed memory transaction scheme 300 shown can be parallelized Figure 2 The two sub-steps of the traditional distributed memory transaction scheme 200 are shown to accelerate its verification and submission phases, especially by managing the locking, verification and submission operations in the manner described below.

[0057] from Figure 4 It can be seen that in this second embodiment, the read set verification (i.e., sub-step 4) and the actual submission (i.e., sub-step 5) are merged, i.e., executed in parallel by each memory node 120a to 120c. Figure 4 In the exemplary scenario shown, the coordinator 110 communicates with the third memory node 120c and instructs the third memory node 120c to lock and verify the write-set object. In an embodiment, the coordinator 110 may also instruct the third memory node 120c to store a backup version of each write-set object owned by the third memory node 120c.

[0058] Once memory node 120c successfully completes verification and storage of the backup of one or more write set objects (and reports it to coordinator 110), coordinator 110 can concurrently communicate with all memory nodes 120a to 120c to instruct the first memory node 120a and the second memory node 120b to verify the read set objects of the first memory node 120a and the second memory node 120b, and to instruct the third memory node 120c to commit the changes made to the write set objects that it has locked in the previous sub-step 3. It should be understood that by storing a backup version of each write set object, Figure 4 Parallelization of the read-set verification (i.e., sub-step 4) and the actual commit (i.e., sub-step 5) in the second embodiment shown is possible. This allows for handling the case where verification of the contents of one of the read-set objects fails while changes to some of the write-set objects are successfully committed, by retaining a backup of each write-set object before it is changed. It will be appreciated that this backup allows for rolling back the changes later in case any other parallelized operations fail.

[0059] exist Figure 4 In the second embodiment shown, if sub-steps 4 and 5 are completed successfully, the coordinator 110 may notify the application of the successful completion of the distributed memory transaction, and then send a notification to all memory nodes hosting the write set object (e.g. Figure 4 The third memory node 120c) in the exemplary embodiment shown sends an unlock message.

[0060] It should be understood that Figure 2Compared with the conventional distributed memory transaction scheme 200 shown in FIG, the second embodiment (similar to the first embodiment) implemented by the controller 110 and the memory nodes 120a to 120c Figure 4 The distributed memory transaction scheme 300 can reduce network round-trip time (RTT) during the validation and commit phases, thereby shortening the time it takes to commit a transaction. For one embodiment, where the distributed memory transaction scheme 300 is executed by the NIC of the controller 110 and / or the corresponding NIC of each memory node in the memory nodes 120a to 120c, synchronous message passing can be offloaded, latency for responses from the host CPU can be reduced, and core cycles can be saved.

[0061] As mentioned above, in Figure 4 In the second embodiment shown, the third memory node 120c is used to store the backup version of each write set object. In an embodiment, each memory node among the memory nodes 120a to 120c, especially the third memory node 120c, can use Figure 5 The data structure for each write-set object, shown in the form of a dual-use scratchpad 500, stores one or more backup versions of the write-set object in a dedicated per-transaction memory space. This memory space can be allocated during the execution phase and can exist throughout the lifecycle of a distributed memory transaction until it commits or aborts.

[0062] In another embodiment, the scratch pad 500 may be used only for each cache line associated with the corresponding write-set object. In this way, the scratch pad 500 only retains those portions of the write-set object that have actually been changed (saving scratch pad memory), which is often very beneficial when processing large write-set objects.

[0063] In an embodiment, each memory node 120a-120c is used to perform all modifications to objects in the staging area 500 during the execution phase of a distributed memory transaction. These changes are visible only to the corresponding transaction. All other transactions always see the original contents in memory. Objects modified by concurrent transactions may have concurrent staging area images, of which only one image will ultimately be committed to main memory. Therefore, it should be understood that in this sense, the use of the staging area 500 is a variant of multi-version concurrency control, in which each transaction accessing an object sees its own staging area for the object.

[0064] In an embodiment, for any object referenced by a transaction, the associated memory nodes 120 a - 120 c are used to look up the object in the associated transaction's staging area 500 for reading or writing. If the object does not yet exist and if it is a write-set object, the corresponding memory nodes 120 a - 120 c may be used to copy the contents of the write-set object from its original memory location to the staging area 500.

[0065] exist Figure 4 In the second embodiment shown (and in Figure 6 In the third embodiment shown in FIG. 1 and described in more detail below, during the validation and commit phases and after taking a write-set object lock in exclusive mode, if supported by the corresponding memory nodes 120 a to 120 c, the contents of the scratch pad 500 of the relevant transaction can be copied to the original memory location of the object, and the scratch pad 500 can be filled with the original memory contents for backup, for example, by using an atomic cache line swap. Before releasing the lock, the contents of the scratch pad 500 can be cleared if the transaction is successfully committed, or copied back to main memory if the transaction is aborted.

[0066] Figure 5 1 illustrates the functionality of the dual-use scratchpad 500 used by the respective memory nodes 120a to 120c for storing respective backups of write-set objects according to an embodiment. Figure 5 In the example, the transaction starts with object X data = X1, updates it to X2, and modifies some other objects. The transaction is successfully committed. In the execution phase (e.g. Figure 5 When a write set object is accessed for the first time, a temporary version is created. Before a transaction is committed, the contents of the temporary version can only be seen by that transaction (e.g. Figure 5 All other transactions see the original memory contents (as shown in Box 2A in the example). Figure 5 If the transaction is aborted (as shown in Box 2B in Figure 5 The corresponding memory nodes 120a to 120c are used to copy the contents of the temporary storage area 500 to the original memory location (such as Figure 5 The temporary storage area 500 now stores the original memory contents as a backup (e.g. Figure 5 If the transaction is fully committed, the corresponding memory nodes 120a to 120c may invalidate the temporary storage area 500, and the contents in the memory may be moved to a normal state (eg, Figure 5 (as shown in block 4 in the example). If the transaction is aborted, the corresponding memory nodes 120a to 120c can copy the contents of the scratch pad back to the original memory location, thereby overwriting the original memory location. Only in this way can the contents on the memory be moved to a normal state and the scratch pad 500 be invalidated.

[0067] Figure 6 The following diagram shows the interaction between a data processing device 110 (e.g., a coordinator 110) and three memory nodes 120a to 120c for executing a distributed memory transaction solution 300 according to the third embodiment. As can be understood from the following more detailed description, Figure 6 The distributed memory transaction scheme 300 shown can be parallelized Figure 2 The three sub-steps of the traditional distributed memory transaction scheme 200 are shown to accelerate its verification and submission phases, especially by managing the locking, verification and submission operations in the manner described below.

[0068] It will be further understood that Figure 6 The distributed memory transaction solution 300 provided by the third embodiment shown can be considered as Figure 3 The distributed memory transaction solution 300 (using shared read locks) provided by the first embodiment shown in FIG. Figure 4 The second embodiment shown provides a combination of a distributed memory transaction solution 300 (using write set object backup). More specifically, in Figure 6 In the third embodiment shown, the locking and verification of the read set object (sub-step 3), the locking of the write set object (sub-step 4), and the commit step (sub-step 5) are performed substantially in parallel by the coordinator 110 and the memory nodes 120a to 120c. Figure 4 As already described in the context of the second embodiment shown, when locking one or more of its write set objects in sub-step 4, the third memory node 120c is used to use e.g. Figure 5 The illustrated scratchpad data structure 500 stores backup versions of one or more write-set objects in a dedicated per-transaction memory space.

[0069] Immediately after the execution phase ends, the coordinator 110 can communicate concurrently with the memory nodes 120a to 120c to instruct the first memory node 120a and the second memory node 120b to verify the read set objects they own, and to instruct the third memory node 120c to lock and verify the write set objects it owns to create a backup thereof (as described above in the context of the second embodiment, using, for example, the staging area data structure 500) and commit the changes to its memory. If all of these operations are successful, the coordinator 110 can, for example, notify the calling application of the successfully committed distributed transaction and send a message to the memory nodes 120a to 120c to release the locks they have acquired. In an embodiment, the memory nodes 120a to 120c can use short lock cycles in the commit phase with different lock semantics to support parallelized read set verification and write set locking.

[0070] As above Figure 4As already described in the context of the second embodiment shown, creating a backup version of each write-set object before committing changes to memory and avoiding unlocking objects before ensuring that all objects have been verified / locked allows the commit sub-step 5 to be parallelized with the other sub-steps 3 and 4. If a verification fails on any of the memory nodes 120a to 120c, that memory node 120a to 120c may notify the coordinator 110 of the failure, which in turn may notify all other memory nodes 120a to 120c that they need to roll back the changes previously committed by those memory nodes 120a to 120c (e.g., using the backups they retain, using the above-described Figure 5 The temporary storage area data structure 500 is described in the context of FIG.

[0071] It should be understood that Figure 2 Compared with the conventional distributed memory transaction solution 200 shown in FIG, the third embodiment provides a distributed memory transaction solution implemented by the controller 110 and the memory nodes 120a to 120c. Figure 6 The distributed memory transaction scheme 300 can even further reduce network round-trip time (RTT) during the validation and commit phases, thereby shortening the time it takes to commit a transaction. For one embodiment, where the distributed memory transaction scheme 300 is executed by the NIC of the controller 110 and / or the corresponding NIC of each of the memory nodes 120a to 120c, synchronous messaging can be offloaded, latency for responses from the host CPU can be reduced, and core cycles can be saved.

[0072] Figure 7 The following diagram shows the interaction between a data processing device 110 (e.g., a coordinator 110) and three memory nodes 120a to 120c for executing a distributed memory transaction solution 300 according to the fourth embodiment. As can be understood from the following more detailed description, Figure 7 The distributed memory transaction scheme 300 shown can be parallelized Figure 2 The three sub-steps of the traditional distributed memory transaction scheme 200 are shown to accelerate its verification and submission phases, especially by managing the locking, verification and submission operations in the manner described below. Figure 7 The distributed memory transaction solution 300 provided by the fourth embodiment is very similar to Figure 6 The third embodiment shown provides a distributed memory transaction solution 300 . Figure 7 The distributed memory transaction scheme 300 shown is similar to Figure 6 The difference of the third embodiment shown is mainly that, based on the assumption that the actual commit operation (using the memory copy of one or more write set objects) will not fail, the relevant memory nodes 120a to 120c do not need to generate and retain backup versions for one or more write set objects.

[0073] More specifically, in Figure 7 In the fourth embodiment shown, the locking and verification of the read set object (sub-step 3) and the locking and verification of the write set object (sub-step 4) are performed in parallel by the memory nodes 120a to 120c. Once the execution phase is over, the coordinator 110 communicates concurrently with the memory nodes 120a to 120c to instruct the first memory node 120a and the second memory node 120b to verify the read set objects they own (and take shared locks on the read set objects they own), and to instruct the third memory node 120c to lock and verify the write set objects it owns without creating a backup version and without committing. In an embodiment, short lock cycles can be used in the verification and commit phases with different lock semantics to support parallelized read set verification and write set locking. If these operations are successful, the coordinator 110 can notify the calling application, for example, that the distributed memory transaction was successfully committed, but the lock has not yet been released.

[0074] The coordinator 110 sends a message to all participating memory nodes 120a to 120c to commit the transaction and release the locks that the memory nodes 120a to 120c have taken. However, if verification fails on any one of the memory nodes 120a to 120c, the memory node 120a to 120c is used to notify the coordinator 110 of the failed verification. In response, the coordinator 110 is used to notify all other memory nodes 120a to 120c to abort the transaction by not performing a commit operation.

[0075] As mentioned above, in Figure 7 In the fourth embodiment shown, the relevant memory nodes 120a to 120c do not need to generate backup versions of one or more write set objects and perform a rollback because the coordinator 110 instructs these memory nodes 120a to 120c to commit only when all verifications have succeeded. It should be understood that in this regard, Figure 7 The fourth embodiment is similar to Figure 3 However, with Figure 3 In contrast to the first embodiment, according to Figure 7 In a fourth embodiment, the coordinator 110 is configured not to wait for the actual commit before notifying, for example, the calling application of a successful transaction. Figure 7 In the fourth embodiment shown, the coordinator 110 optimistically assumes that the commit will succeed, and the notified application can access and act upon the results of the transaction (possibly waiting until a lock is released) once it sees the notification.

[0076] It should be understood that Figure 2 Compared with the conventional distributed memory transaction solution 200 shown in FIG, the fourth embodiment provides a distributed memory transaction solution implemented by the controller 110 and the memory nodes 120a to 120c. Figure 7The distributed memory transaction scheme 300 can even further reduce network round-trip-time (RTT) during the validation and commit phases, thereby shortening the time it takes to commit a transaction without having to allocate memory space to create a backup version of each write-set object. For one embodiment, where the distributed memory transaction scheme 300 is executed by the NIC of the controller 110 and / or the corresponding NIC of each of the memory nodes 120a to 120c, synchronous messaging can be offloaded, latency for responses from the host CPU can be reduced, and core cycles can be saved.

[0077] Figure 8 A flow chart of the operation 800 of the coordinator 110 according to another embodiment is shown, wherein the operation is used to dynamically select one of the previously described embodiments as a different selectable operating mode for executing distributed memory transactions based on actual contention or verification failure rates in a given implementation scenario. To this end, in an embodiment, the coordinator 110 is used to collect statistical data about the performance of the currently used distributed memory transaction mode (i.e., scheme) and may switch to a different operating mode based on the statistical data.

[0078] As can be understood from the above description, the second and third embodiments of the distributed memory transaction scheme 300 are optimistic operating modes because they are based on early commit operations performed independently and concurrently by different memory nodes 120a to 120c. As described above, the distributed memory transaction scheme 300 provided by the second and third embodiments uses a backup and rollback mechanism to maintain a consistent view of memory while maximizing parallelism. Therefore, if a transaction is ultimately aborted, the operating mode of the distributed memory transaction scheme 300 provided by the second and third embodiments can roll back the changes caused by the transaction performed on a certain object. The main reason for the failed transaction that will eventually be aborted may be contention or verification failure for one or more locks. If the probability of contention is low, independent (and parallelized) commit tracking can be retained on each memory node 120a to 120c, and synchronization can be performed only after all memory nodes 120a to 120c have committed their own partial completions.

[0079] As described above, the optional operating mode of the first embodiment of the distributed memory transaction scheme 300 does not employ a backup mechanism because the coordinator 110 waits for all verifications and locks to complete before instructing all memory nodes 120a to 120c to commit their changes. Although it requires an additional RTT, there is no need to provide memory space for the backup version of the write-set object. Therefore, this operating mode of the first embodiment of the distributed memory transaction scheme 300 provides a balance between performance (saving one RTT compared to the traditional distributed memory transaction scheme 200) and the use of memory resources (to retain the backup version until the transaction is fully committed or aborted).

[0080] from Figure 8 It can be seen that in an embodiment, the coordinator 110 can be configured to operate in a pre-commit mode of operation by default (see Figure 8 801) operation, especially the operation mode based on the third embodiment of the distributed memory transaction scheme 300, because this mode is faster and more efficient than other operation modes. However, if the statistics collected by the coordinator 110 indicate poor performance and excessive rollbacks (see Figure 8 803 in ), the coordinator 110 can be used to switch to the late submission operation mode (see Figure 8 805 in ), for example, based on the operating mode of the first embodiment of the distributed memory transaction scheme 300. Once the global and object contention levels fall below the adjustable thresholds again (see Figure 8 807 and 809 in ), the coordinator 110 can be used to return to the early submission mode of operation (see Figure 8 801), for example, based on the operating mode of the third embodiment of the distributed memory transaction 300, and resetting the collection of statistical data.

[0081] In an embodiment, the resolution of statistics and decisions taken by the coordinator 110 may be global or per specific memory object. Figure 8 In the embodiment shown, the coordinator 110 is configured to allocate resources based on the global contention level (in Figure 8 The global contention level may be determined as the ratio of the total number of rollbacks to the total number of successful commits, and / or based on the object contention level (indicated as "g_contl" in Figure 8 denoted as “o_contl” in ), which can be determined by a weighted factorization of: (a) the ratio of objects rolled back to successfully committed; (b) the ratio of objects successfully verified to locked; and / or (c) the ratio of objects written to read.

[0082] Those skilled in the art will understand that the “blocks” (“units”) in the various figures (methods and devices) represent or describe the functions of the embodiments of the present disclosure (and not necessarily independent “units” in hardware or software), thereby equally describing the functions or features of the device embodiments and the method embodiments (unit = step).

[0083] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The described embodiments of the device are merely exemplary. For example, unit division is merely a logical functional division, and other division methods can be used in actual implementation. For example, multiple units or components can be merged or integrated into another system, or some features can be ignored or not performed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be implemented through some interfaces. Indirect coupling or communication connection between devices or units can be implemented through electronic, mechanical or other forms.

[0084] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, and may be located in one location or distributed across multiple network units. Some or all of the units may be selected as needed to achieve the purpose of the embodiments.

[0085] In addition, the functional units in the embodiments disclosed herein may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

Claims

1. A device (110) for managing distributed memory transactions on multiple objects, characterized in that The plurality of objects are stored in a plurality of memory nodes (120a to 120c) of a network of memory nodes (120a to 120c), the distributed memory transaction comprises an execution phase and a verification and commit phase, the plurality of objects comprises one or more read set objects and / or one or more write set objects, wherein, in the verification and commit phase, the apparatus (110) is configured to execute the processing phase: (a) locking and validating the one or more writeset objects; (b) verifying the one or more read set objects; (c) committing changes and unlocking the one or more writeset objects; The device (110) is configured to perform the processing stages (a) and (b) and / or the processing stages (b) and (c) of the verification and submission stages substantially in parallel.

2. The device (110) according to claim 1, characterized in that During the execution phase, the device (110) is further configured to read the atomic version number of each of the plurality of objects to verify the one or more write set objects and / or the one or more read set objects during the verification and commit phase.

3. The device (110) according to claim 1 or 2, characterized in that The device (110) includes a network interface card (NIC) of a server, a memory processor, or a hardware accelerator.

4. The device (110) according to any one of the preceding claims, characterized in that The device (110) is a memory node (110) among the plurality of memory nodes (120a to 120c).

5. The device (110) according to any one of claims 1 to 4, characterized in that The apparatus (110) is configured to perform processing stages (a) and (b) of the verification and submission stages substantially in parallel, wherein the one or more read set objects include a first read set object stored on a first memory node (120a) among the plurality of memory nodes (120a to 120c) and a second read set object stored on a second memory node (120b) among the plurality of memory nodes (120a to 120c), and wherein the data processing apparatus (110) is configured to trigger the first memory node (120a) and the second memory node (120b) to lock the first read set object and the second read set object with a shared lock.

6. The device (110) according to any one of claims 1 to 4, characterized in that The apparatus (110) is configured to perform processing stages (b) and (c) of the verification and commit stages substantially in parallel, and wherein, in stage (b), the apparatus (110) is configured to trigger the one or more memory nodes of the plurality of memory nodes (120a to 120c) storing the one or more write-set objects to generate a backup copy of the corresponding write-set object.

7. The device (110) according to claim 6, characterized in that The device (110) is used to trigger one or more memory nodes among the multiple memory nodes (120a to 120c) storing the one or more write set objects to perform a rollback based on the backup copy of the corresponding write set object in response to receiving information from one or more memory nodes among the multiple memory nodes (120a to 120c) that the verification and commit phase has failed.

8. The device (110) according to any one of claims 1 to 4, characterized in that The apparatus (110) is configured to execute the processing stages (a), (b) and (c) of the verification and submission stages substantially in parallel, wherein the one or more read set objects include a first read set object stored on a first memory node (120a) among the plurality of memory nodes (120a to 120c) and a second read set object stored on a second memory node (120b) among the plurality of memory nodes (120a to 120c), and wherein the data processing apparatus (110) is configured to trigger the first memory node (120a) and the second memory node (120b) to lock the first read set object and the second read set object with a shared lock.

9. The device (110) according to any one of claims 1 to 4, characterized in that The device (110) is used to perform the processing stages (a) and (b) of the verification and commit stage substantially in parallel in a first selectable operating mode, perform the processing stages (b) and (c) of the verification and commit stage substantially in parallel in a second selectable operating mode, and perform the processing stages (a), (b) and (c) of the verification and commit stage substantially in parallel in a third selectable operating mode, and wherein the device (110) is used to select the first selectable operating mode, the second selectable operating mode or the third selectable operating mode for managing the distributed memory transaction.

10. The device (110) according to claim 9, characterized in that The device (110) is used to obtain statistical data of multiple distributed memory transactions executed using a previously selected operating mode, and to select the first selectable operating mode, the second selectable operating mode or the third selectable operating mode for managing the distributed memory transactions based on the statistical data.

11. The device (110) according to claim 10, characterized in that The statistical data acquired by the device (110) includes data indicating a global contention level and / or data indicating an object contention level.

12. A data processing system (100), characterized in that include: a plurality of memory nodes (120a to 120c) for storing memory objects; The apparatus (110) according to any one of the preceding claims, wherein the apparatus (110) is used to manage distributed memory transactions on a plurality of objects stored in the plurality of memory nodes (120a to 120c).

13. A method for managing distributed memory transactions on multiple objects, characterized in that The plurality of objects are stored in a plurality of memory nodes (120a to 120c) of a network of memory nodes (120a to 120c), the distributed memory transaction comprises an execution phase and a verification and commit phase, the plurality of objects comprise one or more read-set objects and / or one or more write-set objects, wherein, in the verification and commit phase, the method comprises the processing phase: (a) locking and validating the one or more writeset objects; (b) verifying the one or more read set objects; (c) committing changes and unlocking the one or more writeset objects, Wherein, the processing stages (a) and (b) and / or the processing stages (b) and (c) of the verification and submission stage are substantially performed in parallel.

14. A computer program product, characterized in that The invention also comprises a computer-readable storage medium for storing program code, which, when executed by a computer or a processor, causes the computer or the processor to perform the method according to claim 13.

Images