A concurrent programming method and device based on software transaction memory

Abstract

The present invention discloses a concurrent programming method and device based on software transaction memory. It belongs to the technical field of computer programming. The concurrent programming method based on software transaction memory designed by the present application is based on a high-speed cache hardware structure that supports exchangeable update perception, supports transaction processing of exchangeable update operations, and dynamically maintains the serial execution graph of sub-transactions, judges the serializability of sub-transactions at the transaction commit node, and enhances the concurrency in the transaction execution process; and concurrently executes sub-transactions and parent transactions based on the characteristics of Future asynchronous programming, reduces the strong correlation between the execution of parent and child transactions, reduces the possibility of transaction rollback and the failure of transaction execution; in addition, provides a variety of parent transaction commit strategies, and the blocking waiting strategy can avoid the problem of global observation inconsistency; the independent commit strategy can improve the efficiency of transaction execution and reduce the scope of influence of transaction rollback.

Description

Technical Field

[0001] The present invention relates to the technical field of computer programming, and in particular to a concurrent programming method and device based on software transaction memory. Background Art

[0002] Software Transactional Memory (STM), as an innovative technology in the field of concurrent programming, provides an effective alternative mechanism to solve traditional locking problems. STM enables synchronization problems in multi-threaded programming to be managed in the form of transactions, does not rely on specific hardware resources, and can effectively handle complex synchronization problems. Its basic principle is to create an execution environment independent of interference from other threads by isolating a set of read and write operations, thereby simplifying the programming model and reducing the frequency of transaction aborts.

[0003] Although STM provides obvious advantages, such as improved concurrency performance and simplified development for programmers, its implementation also brings a series of challenges. First, compared with traditional locking mechanisms, STM needs to record logs for each operation, which will increase significant overhead in high concurrency situations and may cause frequent transaction rollbacks, reducing system efficiency. In addition, most STM models only support independent transaction processing, while transactions in modern multi-threaded environments often require interactive sharing of data, increasing the complexity of design and maintenance.

[0004] Regarding the interaction between transactions, current research work mainly focuses on the following aspects:

[0005] Isolation and interactivity transaction solutions: For example, Smaragdakis et al. proposed a transaction model TIC with isolation and collaboration, which allows data exchange while maintaining atomicity and isolation.

[0006] Combining events and message passing mechanisms. The transaction event TE model of Donnelly et al. and the communicating transaction memory CMT of Lesani et al. solve the synchronization problem between transactions by building communication channels and managing dependencies.

[0007] A solution combining Future features: The introduction of Future, as studied by Swalens et al., can create finer-grained parallelism and sub-transaction generation in transactions, enhancing interactivity and flexibility.

[0008] These studies provide feasibility in theory, but in practical applications they may face the contradiction between serializability and interactivity, as well as the effectiveness of the program. For example, the transaction dependencies of the TC model may lead to deadlocks, while CMT can maintain serializability but cannot handle circular dependencies. In addition, due to the thread relevance of transactions, the use of Future may lead to observation consistency issues, affecting the correctness and availability of the program.

[0009] In summary, software transactional memory provides a powerful concurrent programming mechanism, but it still has certain technical problems in practical applications. Namely, it may cause frequent transaction rollbacks and large overhead under high concurrency conditions. At the same time, it is difficult to effectively handle the interactions and dependencies between transactions, leading to major problems such as serializability and limited program efficiency. Further research is needed to solve the problems of STM and promote the further development of concurrent programming models. Summary of the invention

[0010] In view of the above problems in the prior art, the present invention provides a concurrent programming method and device based on software transactional memory.

[0011] In one aspect, a concurrent programming method based on software transactional memory is provided, the method comprising:

[0012] Define a basic execution command, wherein the basic execution command includes a command for creating a subtransaction, wherein the subtransaction is created by a parent transaction and the parent transaction also includes a transaction for continuing to execute after the subtransaction is created;

[0013] When executing the create subtransaction command, the subtransaction is executed asynchronously as a Future task and is executed concurrently with the continuing transaction, wherein the starting state of the subtransaction is the same as that of the continuing transaction;

[0014] In response to the existence of a subtransaction submission, judging whether the subtransaction and the continuing transaction can be safely executed in parallel according to node information of a directed acyclic graph, wherein the directed acyclic graph is generated when the subtransaction is executed serially;

[0015] If it is safe to run in parallel, the execution of the sub-transaction is submitted to be globally visible;

[0016] If safe parallelism is not possible, keep the outer transaction running and roll back the subtransaction to before execution;

[0017] When the parent transaction is merged, all operations of the parent transaction are made visible to the sub-transactions, and then the sub-transactions to be submitted are re-executed and the modified status is uniformly submitted at the merge point;

[0018] In response to the parent transaction committing, wait for all child transactions to commit before committing;

[0019] In response to a sub-transaction commit failure, the parent transaction is rolled back to a state before execution.

[0020] Optionally, when the parent transaction is merged, all operations of the parent transaction are made visible to the child transaction, and then the subtransactions to be submitted are re-executed and completed and the modified states are uniformly submitted at the merge point, and the method further includes:

[0021] In response to the parent transaction being committed, determining whether the read value of the committed child transaction is in the latest state;

[0022] If it is the latest status, the parent transaction is directly submitted.

[0023] Optionally, the basic execution commands also include a start command, a merge subtransaction command, a commit command and a terminate command.

[0024] Optionally, after defining the basic execution command, the method further includes:

[0025] Each transaction performs a read and commutative update operation on the memory, where the value of the read location and the updated value of the memory form a commutative semigroup;

[0026] Non-transactional statements read, write, and commutatively update memory.

[0027] Optionally, each outermost transaction maintains a directed acyclic graph of serial execution of related sub-transactions, where the nodes in the directed acyclic graph are related to the sub-transactions, and each node of the directed acyclic graph contains a set of operations on the memory by the corresponding execution part, and the direction of the connection between each node represents the order of execution.

[0028] Optionally, in response to the existence of a subtransaction submission, judging whether the subtransaction and the continuing transaction can be safely executed in parallel according to the node information of the directed acyclic graph includes:

[0029] When two nodes corresponding to the subtransaction and the continuing transaction in the directed acyclic graph are unreachable, determining that the subtransaction is safely executed in parallel with the continuing transaction;

[0030] When two nodes corresponding to the subtransaction and the continuing transaction in the directed acyclic graph are reachable, it is determined that the subtransaction and the continuing transaction cannot be safely executed in parallel.

[0031] On the other hand, a concurrent programming device based on software transaction memory is provided, the device comprising:

[0032] A command definition module, used for defining basic execution commands, wherein the basic execution commands include a command for creating a sub-transaction, wherein the sub-transaction is created by a parent transaction and the parent transaction also includes a transaction for continuing execution after the sub-transaction is created;

[0033] A command execution module, configured to execute the subtransaction as a Future task asynchronously and concurrently with the continuing transaction when executing the create subtransaction command, wherein the starting state of the subtransaction is the same as that of the continuing transaction;

[0034] A first commit module, configured to, in response to a subtransaction commit, determine whether the subtransaction and the continuing transaction can be safely executed in parallel according to node information of a directed acyclic graph, wherein the directed acyclic graph is generated when the subtransaction is executed serially;

[0035] A globally visible module, used for submitting the execution of the sub-transaction to be globally visible if it is safe to run in parallel;

[0036] A sub-transaction rollback module is used to keep the outer transaction running and roll back the sub-transaction to before the execution if safe parallelism is not possible;

[0037] The second commit module is used to make all operations of the parent transaction visible to the sub-transaction when the parent transaction is merged, and then re-execute the sub-transaction to be committed and uniformly commit the modified status at the merge point;

[0038] A parent transaction commit module, used to respond to the existence of a parent transaction commit and wait for all sub-transactions to be committed before committing;

[0039] The parent transaction rollback module is used to roll back the parent transaction to a state before execution in response to a sub-transaction submission failure.

[0040] On the other hand, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is loaded and executed by a processor to implement the concurrent programming method based on software transactional memory as described above.

[0041] The present invention has at least the following beneficial effects.

[0042] The present application designs a concurrent programming method based on software transaction memory, which is based on a high-speed cache hardware structure that supports exchangeable update perception, supports transaction processing of exchangeable update operations, and enhances the concurrency of transaction execution by dynamically maintaining a sub-transaction serial execution graph and judging the serializability of sub-transactions at a transaction commit node. Sub-transactions and parent transactions are executed concurrently based on the characteristics of Future asynchronous programming, which reduces the strong correlation between parent and child transaction executions, and reduces the possibility of transaction rollbacks and transaction execution failures. In addition, a variety of parent transaction commit strategies are provided, and a blocking wait strategy can avoid the problem of global observation inconsistency. An independent commit strategy can improve transaction execution efficiency and reduce the impact of transaction rollbacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 A method flow chart of a concurrent programming method based on software transactional memory provided schematically for this application;

[0044] Figure 2 A schematic diagram of the internal snapshot process when creating a sub-transaction is provided for the purpose of illustration in this application;

[0045] Figure 3 A schematic diagram of a directed acyclic graph generation process provided schematically for this application;

[0046] Figure 4 The serial execution analysis module instruction flow chart provided schematically for this application;

[0047] Figure 5 A schematic diagram of the parent transaction commit and rollback strategy provided for illustration purposes only. DETAILED DESCRIPTION

[0048] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0049] The term "multiple" as used herein refers to two or more than two. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0050] Example 1.

[0051] Therefore, in view of the above problems in the prior art, a concurrent programming method based on software transactional memory is provided. Based on the software transactional memory model and the commutative update-aware cache hardware structure, concurrent programming is performed in combination with the characteristics of asynchronous programming. Under the condition of ensuring that transactions are serializable and deadlock-free, the characteristics of commutative updates are used to improve the interactivity and execution efficiency of transactions. Figure 1 As shown, the method includes the following contents.

[0052] Step 101, define basic execution commands, which include creating sub-transaction commands.

[0053] A subtransaction is created by a parent transaction and the parent transaction also includes a transaction that continues after the creation of the subtransaction.

[0054] Optionally, the basic execution commands also include the start command, merge subtransaction command, commit command, and terminate command. With the support of the commutative update-aware cache hardware structure, memory can be read and commutatively updated during transaction execution. In addition, the non-transactional part of the memory operation is defined, including memory read, write, and commutative update operations.

[0055] In order to facilitate quick understanding of various parameters or processes in concurrent programming, some processes and parameters are abbreviated.

[0056] This step can also be understood as defining the basic execution commands of the transaction, including start (txn_start), create subtransaction (txn_spawn), merge subtransaction (txn_join), commit (txn_commit), and terminate (txn_abort). After the parent transaction T creates the subtransaction T', the part that continues to be executed is called C(T'), that is, the composition of the parent transaction T is: the part before creating T' + C(T'). With the support of the commutative update-aware cache hardware structure, transactions can perform read (r) and commutative update (cu) operations on the memory. Among them, the read operation r(a) means reading the value of the memory position a; the commutative update operation cu(a, u) means using the update u to operate on the value of the memory position a, where it is necessary to satisfy (the value of the memory position a, u) to form a commutative semigroup.

[0057] In addition, non-transactional statements can read (r), write (w), and commutative update (cu) operations on memory. The added write operation w(a, v) means writing the value v to the memory location a.

[0058] That is, after step 101, the method further includes:

[0059] Step 1: Each transaction performs a read and commutative update operation on the memory, wherein the value of the read position and the update value of the memory form a commutative semigroup;

[0060] Step 2: Non-transactional statements read, write, and exchangeably update memory.

[0061] Among them, each outermost transaction maintains a directed acyclic graph of serial execution of related sub-transactions. The nodes in the directed acyclic graph are related to the sub-transactions, and each node of the directed acyclic graph contains a set of operations on the memory of the corresponding execution part, and the connection direction between each node represents the order of execution.

[0062] Step 102: When executing the create sub-transaction command, the sub-transaction is executed asynchronously as a Future task and is executed concurrently with the continuing transaction.

[0063] The starting state of the subtransaction is the same as that of the continuing transaction.

[0064] In a possible implementation, an internal snapshot operation is performed when a create subtransaction command is executed, that is, when the "create subtransaction" command is executed, the subtransaction is executed asynchronously as a Future task, and the operations executed by the parent transaction are visible to the subtransaction, so that the subtransaction and the part that continues to execute the parent transaction are based on the same state.

[0065] In an example, when the parent transaction T uses the "create subtransaction" txn_spawn(T') command, the subtransaction T' is executed asynchronously as a Future task, the internal state snapshot of the parent transaction T, and the executed operation tx_start(T) is visible to the subtransaction T', that is, the starting state of the subtransaction T' is the same as the part C(T') that continues to execute the parent transaction, retaining the potential concurrency, T' and C(T') are executed concurrently, and serializability is judged at the commit point. The specific meaning is as follows Figure 2 shown.

[0066] Furthermore, steps 103 to 106 describe the commit and rollback strategies of the subtransaction.

[0067] Step 103 , in response to the existence of a sub-transaction submission, it is determined whether the sub-transaction and the continuing transaction can be safely executed in parallel according to the node information of the directed acyclic graph.

[0068] Among them, a directed acyclic graph is generated when sub-transactions are executed serially.

[0069] The process of generating a directed acyclic graph is as follows Figure 3As shown. The graph generation process begins. First, take the next transaction T in the outer transaction sequence and represent it as txn_start (T); the new node generated is recorded as Vt, and the new edge is generated, where the new edge is generated as the last node of the current graph pointing to Vt; determine whether to execute the creation of the subtransaction txn_spawn (T'), if so, generate new nodes and record them as Vt' and Vtc. New edges are generated, and the new edges are Vt pointing to Vt' and Vtc. If not, transaction T is committed, recorded as txn_commit (T); determine whether to execute the creation of internal subtransactions, if so, merge subtransactions and record them as txn_join (T, T'), generate a new node Vtt', generate new edges, and the new edges are Vt' and Vtc pointing to Vtt', and the next transaction T is committed, recorded as txn_commit (T), if not, continue to generate internal subtransaction nodes and merge internal subtransaction nodes and add directed edges according to the rules; then determine whether there is a next transaction in the outer transaction, if yes, continue to execute the step of taking the next transaction T in the outer transaction sequence, otherwise end the process.

[0070] Step 104: If it is safe to run in parallel, the execution of the sub-transaction is submitted to be globally visible.

[0071] Step 105: If safe parallelism is not possible, the outer transaction is kept executing and the sub-transaction is rolled back to before execution.

[0072] In a possible implementation, each outermost transaction maintains a directed acyclic graph of serial execution of related subtransactions, where the nodes in the graph are related to the subtransactions, and each node V contains a set of operations on the memory by the corresponding execution part {a->{op | op belongs to r, cu} | a is a set of memory locations accessed by the corresponding execution part}, and the direction of the connection between the nodes represents the order of execution.

[0073] At the beginning of the outermost transaction T, the graph is initialized, with only one root node (Vt). When the subtransaction is generated using the txn_spawn(T') command, two new nodes are generated, representing the Future task node (Vt') that executes the subtransaction and the node (Vtc) that continues to execute the parent transaction, and the operation set information of each node is updated. Two directed edges are sent from the node Vt to connect the two new nodes Vt' and Vtc. Subsequent subtransaction creation uses the same method to generate nodes and edges.

[0074] When the merge subtransaction txn_join(T, T') command is used, a directed edge is sent from the Future task node (Vt') of subtransaction T' and the node that continues to execute the parent transaction (Vtc) to connect to a newly added merge node (Vtt').

[0075] Step 106, when the parent transaction is merged, all operations of the parent transaction are made visible to the sub-transactions, and then the sub-transactions to be committed are re-executed and the modified status is uniformly committed at the merge point.

[0076] In a possible implementation, a transaction serial analysis module is constructed, through which the serializable relationship between transactions and access conflicts are analyzed. The core part of this module is a directed acyclic graph of serial execution of related sub-transactions maintained by each outermost transaction. When a sub-transaction needs to be submitted, the serial analysis module calculates the node information of the directed acyclic graph to determine whether potential transactions can be safely parallelized. If they can be safely parallelized, the execution of the sub-transaction is directly submitted to the global visibility; otherwise, without interfering with the continued execution of the outer transaction, the sub-transaction is only rolled back to before execution. When the parent transaction performs a transaction merge, all operations of the current parent transaction are visible to the sub-transaction, and then the sub-transaction to be submitted is re-executed and the modified status is uniformly submitted at the merge point.

[0077] For the commit and rollback of subtransactions, when a subtransaction is committed, the serial execution analysis module is used to determine the concurrency relationship between transactions and whether the serializable relationship is satisfied.

[0078] 1) Concurrent execution node judgment: When two nodes in a directed graph are unreachable, it means that the execution order between the two nodes is unclear in the execution graph, and the two nodes are executed concurrently. Therefore, when subtransactions T1 and T2 are unreachable in the graph, it means that subtransactions T1 and T2 are executed concurrently.

[0079] 2) Sub-transaction T1 submission strategy: If transactions T1 and T2 do not have shared memory location operations, transaction T1 can be directly submitted to global visibility.

[0080] The specific process is as follows Figure 4 As shown. First, subtransaction T1 is ready to be submitted, and enters the concurrent execution node judgment module to determine whether transactions T1 and T2 have accessed the shared memory location. If so, the operation effects of T1 and T2 on each shared location are merged respectively (see Table 1 for the merge calculation rules), and then the operation effects of T1 and T2 on each shared location are superimposed (see Table 2 for the superimposed calculation rules). If the superimposed calculation results for each shared memory location are not x, then it is submitted to global visibility, otherwise T1 is rolled back to the state before T1 is executed; if transactions T1 and T2 do not access the shared memory location, it is submitted to global visibility; after T1 is rolled back to the state before T1 is executed, it is determined whether the execution effect of T2 is visible to T1, if not, the judgment is looped, and if so, T1 is re-executed and submitted to global visibility; after being submitted to global visibility, no operation is performed until the subtransaction T1 is submitted.

[0081] The following only analyzes the shared memory location operations in subtransactions T1 and T2. First, all the operation effects of each shared memory location of subtransactions T1 and T2 are combined and calculated in the order of execution (the rules are shown in Table 1).

[0082] Table 1 Merger calculation rules

[0083]

[0084] The operation effects of subtransactions T1 and T2 on the same shared memory location are superimposed and calculated (the rules are as shown in Table 2).

[0085] Table 2 Superposition calculation rules

[0086]

[0087] If the result of the superposition calculation of all shared memory operation effects is not "×", it means that subtransaction T1 can be directly submitted to the global visibility. If the result of the superposition calculation of the operation effect of a shared memory location is "×", subtransaction T1 needs to be rolled back and re-executed after T2. Before T1 is re-executed, the execution effect of T2 needs to be visible to T1.

[0088] Furthermore, steps 107 to 108 describe the commit and rollback strategies of the parent transaction.

[0089] Step 107, in response to the existence of a parent transaction commit, wait for all child transactions to be committed before committing.

[0090] Step 108: In response to a sub-transaction commit failure, the parent transaction is rolled back to a state before execution.

[0091] Two different strategies are provided in the embodiment of the present application, which need to be defined in advance according to application requirements. One is to block and wait for all sub-transactions to be submitted before submission. If a sub-transaction fails to submit, it will roll back to the state before the parent transaction is executed; the other is to submit directly without waiting for all sub-transactions to be submitted. This method requires verification of whether the read value of the sub-transaction that has not been submitted is still the latest state, that is, in response to the existence of the parent transaction submission, it is determined whether the read value of the submitted sub-transaction is the latest state. If it is the latest state, it still meets the transaction serialization condition, and the parent transaction is submitted directly. If a sub-transaction fails to submit under this strategy, it will only roll back to the state before the corresponding failed sub-transaction is executed.

[0092] Specifically, Figure 5As shown. First, the parent transaction is ready to commit, and it is determined whether it is blocked and waiting for commit. If so, it is further determined whether the sub-transactions have all been committed. If all have been committed, it enters path ①. If not, it enters path ②. In path ①, the parent transaction is committed, and then it is determined whether it comes from path ①. If so, the judgment process of the parent transaction submission is completed and ended. If it does not come from path ①, it is determined whether the sub-transaction has been committed. If the sub-transaction has not been committed, the sub-transaction is rolled back to the time before the sub-transaction was executed and re-executed. After the re-execution is completed, the judgment process of the parent transaction submission is completed. If the sub-transaction is completed, the parent transaction submission is completed. The transaction commit judgment process ends here; in path ②, the parent transaction is committed first, and then it is determined whether it comes from path ①. If it does, the parent transaction commit judgment process is completed. If it does not come from path ①, it is determined whether the child transaction has completed the commit. If the child transaction has not completed the commit, the child transaction is rolled back to before the execution of the child transaction and re-executed. After the re-execution is completed, the parent transaction commit judgment process is completed and ended; if the first judgment on whether all child transactions have completed the commit is negative, the parent transaction is rolled back to before all child transactions are executed; after completion, enter path ① and complete the parent transaction commit judgment process and ended.

[0093] The present application designs a concurrent programming method based on software transaction memory, which is based on a high-speed cache hardware structure that supports exchangeable update perception, supports transaction processing of exchangeable update operations, and enhances the concurrency of transaction execution by dynamically maintaining a sub-transaction serial execution graph and judging the serializability of sub-transactions at a transaction commit node. Sub-transactions and parent transactions are executed concurrently based on the characteristics of Future asynchronous programming, which reduces the strong correlation between parent and child transaction executions, and reduces the possibility of transaction rollbacks and transaction execution failures. In addition, a variety of parent transaction commit strategies are provided, and a blocking wait strategy can avoid the problem of global observation inconsistency. An independent commit strategy can improve transaction execution efficiency and reduce the impact of transaction rollbacks.

[0094] Example 2.

[0095] Optionally, in response to the existence of a subtransaction submission, determining whether the subtransaction and the continuing transaction can be safely executed in parallel according to the node information of the directed acyclic graph includes:

[0096] When the two nodes corresponding to the sub-transaction and the continuing transaction in the directed acyclic graph are unreachable, the sub-transaction and the continuing transaction are ensured to be safe and parallel;

[0097] When two nodes corresponding to the subtransaction and the continued transaction in the directed acyclic graph are reachable, it is determined that the subtransaction and the continued transaction cannot be safely executed in parallel.

[0098] On the other hand, a concurrent programming device based on software transaction memory is provided, the device comprising:

[0099] A command definition module, used for defining basic execution commands, wherein the basic execution commands include a command for creating a sub-transaction, wherein the sub-transaction is created by a parent transaction and the parent transaction also includes a transaction for continuing execution after the sub-transaction is created;

[0100] A command execution module, configured to execute the subtransaction as a Future task asynchronously and concurrently with the continuing transaction when executing the create subtransaction command, wherein the starting state of the subtransaction is the same as that of the continuing transaction;

[0101] A first commit module, configured to, in response to a subtransaction commit, determine whether the subtransaction and the continuing transaction can be safely executed in parallel according to node information of a directed acyclic graph, wherein the directed acyclic graph is generated when the subtransaction is executed serially;

[0102] A globally visible module, used for submitting the execution of the sub-transaction to be globally visible if it is safe to run in parallel;

[0103] A sub-transaction rollback module is used to keep the outer transaction running and roll back the sub-transaction to before the execution if safe parallelism is not possible;

[0104] The second commit module is used to make all operations of the parent transaction visible to the sub-transaction when the parent transaction is merged, and then re-execute the sub-transaction to be committed and uniformly commit the modified status at the merge point;

[0105] A parent transaction commit module, used to respond to the existence of a parent transaction commit and wait for all sub-transactions to be committed before committing;

[0106] The parent transaction rollback module is used to roll back the parent transaction to a state before execution in response to a sub-transaction submission failure.

[0107] Optionally, after the second submission module, the device further includes:

[0108] A third commit module, configured to determine whether the read value of the committed subtransaction is the latest state in response to the existence of the parent transaction commit;

[0109] The fourth submission module is used to directly submit the parent transaction if it is the latest state.

[0110] Optionally, the basic execution commands also include a start command, a merge subtransaction command, a commit command and a terminate command.

[0111] Optionally, after the command definition module, the device further includes:

[0112] Each transaction performs a read and commutative update operation on the memory, where the value of the read location and the updated value of the memory form a commutative semigroup;

[0113] Non-transactional statements read, write, and commutatively update memory.

[0114] Optionally, each outermost transaction maintains a directed acyclic graph of serial execution of related sub-transactions, where the nodes in the directed acyclic graph are related to the sub-transactions, and each node of the directed acyclic graph contains a set of operations on the memory by the corresponding execution part, and the direction of the connection between each node represents the order of execution.

[0115] Optionally, the first submission module includes:

[0116] A first committing unit, configured to determine that the subtransaction is safely concurrent with the continuing transaction when two nodes corresponding to the subtransaction and the continuing transaction in the directed acyclic graph are unreachable;

[0117] The second committing unit is configured to determine that the subtransaction and the continuing transaction cannot be safely executed in parallel when two nodes corresponding to the subtransaction and the continuing transaction in the directed acyclic graph are reachable.

[0118] On the other hand, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is loaded and executed by a processor to implement the concurrent programming method based on software transactional memory as described above.

[0119] The above are only optional implementations of the present invention. The protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. A concurrent programming method based on software transactional memory, characterized in that: The method comprises: Define a basic execution command, wherein the basic execution command includes a command for creating a subtransaction, wherein the subtransaction is created by a parent transaction and the parent transaction also includes a transaction for continuing to execute after the subtransaction is created; When executing the create subtransaction command, the subtransaction is executed asynchronously as a Future task and is executed concurrently with the continuing transaction, wherein the starting state of the subtransaction is the same as that of the continuing transaction; In response to the existence of a subtransaction submission, judging whether the subtransaction and the continuing transaction can be safely executed in parallel according to node information of a directed acyclic graph, wherein the directed acyclic graph is generated when the subtransaction is executed serially; If it is safe to run in parallel, the execution of the sub-transaction is submitted to be globally visible; If safe parallelism is not possible, keep the outer transaction running and roll back the subtransaction to before execution; When the parent transaction is merged, all operations of the parent transaction are made visible to the sub-transactions, and then the sub-transactions to be submitted are re-executed and the modified status is uniformly submitted at the merge point; In response to the parent transaction committing, wait for all child transactions to commit before committing; In response to a sub-transaction commit failure, the parent transaction is rolled back to a state before execution.

2. The method according to claim 1, characterized in that When the parent transaction is merged, all operations of the parent transaction are made visible to the child transaction, and then the child transaction to be submitted is re-executed and the modification status is uniformly submitted at the merge point. The method further includes: In response to the parent transaction being committed, determining whether the read value of the committed child transaction is in the latest state; If it is the latest status, the parent transaction is directly submitted.

3. The method according to claim 1, characterized in that The basic execution commands also include a start command, a merge subtransaction command, a commit command and a terminate command.

4. The method according to claim 1, characterized in that After defining the basic execution command, the method further includes: Each transaction performs a read and commutative update operation on the memory, where the value of the read location and the updated value of the memory form a commutative semigroup; Non-transactional statements read, write, and commutatively update memory.

5. The method according to claim 1, characterized in that Each outermost transaction maintains a directed acyclic graph of serial execution of related sub-transactions, where the nodes in the directed acyclic graph are related to the sub-transactions, and each node of the directed acyclic graph contains a set of operations on the memory of the corresponding execution part, and the direction of the connection between each node represents the order of execution.

6. The method according to claim 1, characterized in that In response to the existence of a sub-transaction submission, judging whether the sub-transaction and the continuing transaction can be safely executed in parallel according to the node information of the directed acyclic graph includes: When two nodes corresponding to the subtransaction and the continuing transaction in the directed acyclic graph are unreachable, determining that the subtransaction is safely executed in parallel with the continuing transaction; When two nodes corresponding to the subtransaction and the continuing transaction in the directed acyclic graph are reachable, it is determined that the subtransaction and the continuing transaction cannot be safely executed in parallel.

7. A concurrent programming device based on software transactional memory, characterized in that: The device comprises: A command definition module, used for defining basic execution commands, wherein the basic execution commands include a command for creating a sub-transaction, wherein the sub-transaction is created by a parent transaction and the parent transaction also includes a transaction for continuing execution after the sub-transaction is created; A command execution module, configured to execute the subtransaction as a Future task asynchronously and concurrently with the continuing transaction when executing the create subtransaction command, wherein the starting state of the subtransaction is the same as that of the continuing transaction; A first commit module, configured to, in response to a subtransaction commit, determine whether the subtransaction and the continuing transaction can be safely executed in parallel according to node information of a directed acyclic graph, wherein the directed acyclic graph is generated when the subtransaction is executed serially; A globally visible module, used for submitting the execution of the sub-transaction to be globally visible if it is safe to run in parallel; A sub-transaction rollback module is used to keep the outer transaction running and roll back the sub-transaction to before the execution if safe parallelism is not possible; The second commit module is used to make all operations of the parent transaction visible to the sub-transaction when the parent transaction is merged, and then re-execute the sub-transaction to be committed and uniformly commit the modified status at the merge point; A parent transaction commit module, used to respond to the existence of a parent transaction commit and wait for all sub-transactions to be committed before committing; The parent transaction rollback module is used to roll back the parent transaction to a state before execution in response to a sub-transaction submission failure.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the concurrent programming method based on software transactional memory as described in any one of claims 1 to 6 above.

Images