CN113139873B - Method and apparatus for concurrently executing transactions in blockchain - Google Patents

Abstract

Embodiments of the present specification provide a method and apparatus for concurrently executing transactions in a blockchain, the method being executed at a first node in the blockchain, comprising: after a first executive body in a first node performs a preset operation in the process of processing a first transaction, recording a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in a preset memory, so as to enter a waiting process relative to the first transaction, wherein the preset memory is only accessible by the first executive body; for a plurality of tasks to be processed which are already recorded in the preset memory, determining whether the tasks to be processed waiting for ending the process exist in the tasks to be processed; and continuing to execute a second to-be-processed task of the plurality of to-be-processed tasks based on the execution information corresponding to the second to-be-processed task when it is determined that the waiting process corresponding to the second to-be-processed task is ended.

Description

Method and apparatus for concurrently executing transactions in blockchain

The application relates to a divisional application of an application patent application with the application number 201910816517.0 which is filed on 8/30/2019 and is named as a method and a device for concurrently executing transactions in a blockchain.

Technical Field

Embodiments of the present disclosure relate to the field of blockchain technology, and more particularly, to a method and apparatus for concurrently executing transactions in a blockchain.

Background

The blockchain technology is constructed on a point-to-point (P2P) network, uses a chained data structure to verify and store data, uses a distributed node consensus algorithm to generate and update data, uses a cryptography mode to ensure the safety of data transmission and access, and uses an intelligent contract composed of automatic script codes to program and operate a brand new distributed infrastructure and calculation paradigm of the data. Blockchain technology, also known as distributed ledger technology, is a decentralized distributed database technology that is characterized by decentralization, openness, transparency, non-tampering, and trustworthiness. Each piece of data of the blockchain is broadcast to blockchain nodes of the whole network, and each whole node has a whole amount of consistent data. Nodes in the blockchain transfer and store data by sending transactions, accounting nodes in the blockchain collect transactions in the blockchain in a transaction pool, execute the transactions, and package and spread the transactions into the blockchain after executing the transactions. The validation node in the blockchain validates the blocks sent from the accounting node, and after validation passes, each node executes each transaction included in the block when it is received. In order to ensure the consistency of the data of each node, when executing a plurality of transactions in a block, the submitting sequence of the plurality of transactions needs to be consistent, so that a consistent execution result can be obtained. Therefore, in the prior art, before executing the transaction, the accounting node numbers the plurality of transactions to be executed according to a predetermined rule, and sequentially executes the plurality of transactions according to the order of the numbers, that is, sequentially submits the plurality of transactions, and after receiving the block, the other nodes sequentially execute and submit the plurality of transactions according to the order of the transaction numbers. However, the multiple transactions are not necessarily all interdependent, and in the event that there is no dependency between two transactions, the concurrent execution of the two transactions does not affect the final result. If there is a dependency on two transactions performed concurrently, the concurrent execution will affect the final result.

Thus, there is a need for a more efficient method of concurrently executing multiple transactions in a blockchain.

Disclosure of Invention

Embodiments of the present specification aim to provide a more efficient solution for concurrently executing transactions, which addresses the deficiencies in the prior art.

To achieve the above object, an aspect of the present disclosure provides a method for concurrently executing transactions in a blockchain, the method being executed at a first node in the blockchain, the first node having a first executable preset therein, the first executable currently processing a first transaction, the method being executed by the first executable, including:

After a preset operation is carried out in the process of processing a first transaction, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed are recorded in a preset memory, so that a waiting process is carried out relative to the first transaction, and the preset memory is only accessible by the first execution body;

for a plurality of tasks to be processed which are already recorded in the preset memory, determining whether the tasks to be processed waiting for ending the process exist in the tasks to be processed; and

And continuously executing the second to-be-processed task based on the execution information corresponding to the second to-be-processed task under the condition that the waiting process corresponding to the second to-be-processed task is determined to be ended, wherein the plurality of to-be-processed tasks comprise the second to-be-processed task.

In one embodiment, the method further includes, in the event that it is determined that the waiting process of each of the plurality of tasks to be processed has not ended, retrieving a second transaction to be processed from a first buffer in the shared memory, and beginning execution of the second transaction.

In one embodiment, the predetermined memory includes a second buffer, where after performing the predetermined operation in the process of processing the first transaction, recording in the predetermined memory a first task to be processed corresponding to the first transaction, and the execution information corresponding to the first task to be processed includes, after processing the first transaction, recording in the second buffer, in a case where it is determined that the second transaction is not submitted, the first task to be processed corresponding to the first transaction, where the second transaction is a previous transaction of the first transaction according to a predetermined submitting order.

In one embodiment, for the plurality of pending tasks already recorded in the predetermined memory, determining whether there is a pending task for which a waiting process ends includes determining whether a waiting process for a pending task corresponding to a minimum transaction number in the second buffer is ended based on a transaction currently to be submitted recorded in the shared memory, to determine whether there is a pending task for which a waiting process ends in the second buffer, wherein the transaction number corresponds to a commit order of the transactions.

In one embodiment, in a case where it is determined that the waiting process corresponding to the second task to be processed ends, continuing to execute the second task to be processed based on the execution information corresponding to the second task to be processed includes, in a case where it is determined that the waiting process of the second task to be processed in the second buffer ends, continuing to execute the submission of the third transaction based on the execution information corresponding to the second task to be processed, wherein the second task to be processed corresponds to the third transaction.

In one embodiment, the predetermined memory includes a third buffer, the first transaction includes a read operation on a first variable, where after performing the predetermined operation in a process of processing the first transaction, recording a first task to be processed corresponding to the first transaction in the predetermined memory, and the execution information corresponding to the first task to be processed includes, after requesting the read operation on the first variable, recording the first task to be processed corresponding to the first transaction in the third buffer, where the first task to be processed includes a record on the first variable.

In one embodiment, the third buffer includes the second task to be processed, where the second task to be processed corresponds to a read operation on a second variable in a second transaction, and for a plurality of tasks to be processed that have been recorded in the predetermined memory, determining whether there is a task to be processed in which a waiting process ends includes determining whether a variable value of the second variable is returned, and determining that the waiting process of the second task to be processed ends in a case where it is determined that the variable value of the second variable is returned.

In one embodiment, for the plurality of tasks to be processed already recorded in the predetermined memory, determining whether there is a task to be processed in which the waiting process ends includes, for the plurality of tasks to be processed already recorded in the third buffer, sequentially determining whether the waiting process of each task to be processed ends based on an order of a smaller transaction number corresponding to each task to be processed, where the second task to be processed is a task to be processed in which the waiting process ends determined for the first time, where the transaction number corresponds to a predetermined commit order of transactions.

In one embodiment, determining whether the variable value of the second variable is returned includes determining whether the variable value of the second variable is returned based on whether the variable value of the second variable is stored at a predetermined address, wherein the predetermined address corresponds to the first executable and the second transaction.

In one embodiment, in a case where it is determined that the waiting process corresponding to the second task to be processed ends, continuing to execute the second task to be processed based on the execution information corresponding to the second task to be processed includes, in a case where it is determined that there is the second task to be processed in the third buffer that the waiting process ends, continuing to execute the second transaction based on the execution information corresponding to the second task to be processed and the variable value of the second variable.

In one embodiment, the predetermined memory includes a fourth buffer, the first transaction includes a read operation on the first variable, where after performing the predetermined operation in the process of processing the first transaction, recording a first task to be processed corresponding to the first transaction in the predetermined memory, and the execution information corresponding to the first task to be processed includes, after executing the code to the read operation, determining whether each transaction that is before the first transaction and is not submitted is a conflict transaction in which a write operation on the first variable has been performed, where each transaction includes a second transaction, and in a case where it is determined that the second transaction is the conflict transaction closest to the first transaction, recording the first task to be processed corresponding to the first transaction in the fourth buffer, where the first task to be processed includes a record of the second transaction.

In one embodiment, for the plurality of pending tasks already recorded in the predetermined memory, determining whether there is a pending task waiting for the end of the process includes determining whether there is a pending task waiting for the end of the process among the plurality of pending tasks recorded in the fourth buffer based on a transaction currently submitted recorded in the shared memory.

In one embodiment, the predetermined memory includes a fifth buffer, the first transaction includes a read operation on the first variable, after the predetermined operation is performed in the process of processing the first transaction, recording a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in the predetermined memory includes, after executing the code to the read operation, deducing whether each transaction which is before the first transaction and is not submitted is a conflict transaction to be performed on the first variable in the commit order, wherein each transaction includes a second transaction, and recording the first task to be processed corresponding to the first transaction in the fifth buffer in the case that the second transaction is deduced to be the conflict transaction closest to the first transaction, wherein the first task to be processed includes a record of the second transaction.

In one embodiment, the predetermined memory includes at least one buffer zone, where the at least one buffer zone corresponds to at least one task to be processed, and determining whether there is a task to be processed waiting for ending of the process for a plurality of tasks to be processed already recorded in the predetermined memory includes determining whether there is a task to be processed waiting for ending of the process in each buffer zone based on a predetermined sequence of the at least one buffer zone.

Another aspect of the present disclosure provides an apparatus for concurrently executing transactions in a blockchain, the apparatus being deployed in a first executing body of a first node in the blockchain, the first node having a first executing body preset therein, the first executing body currently processing a first transaction, the apparatus comprising:

A recording unit configured to record, after a predetermined operation is performed in a process of processing a first transaction, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in a predetermined memory, so as to enter a waiting process with respect to the first transaction, the predetermined memory being accessible only by the first executor;

a determining unit configured to determine, for a plurality of tasks to be processed that have been recorded in the predetermined memory, whether there is a task to be processed in which a waiting process ends; and

And the continuous execution unit is configured to continuously execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task when the waiting process corresponding to the second to-be-processed task is determined to be ended, wherein the plurality of to-be-processed tasks comprise the second to-be-processed task.

In one embodiment, the apparatus further includes a transaction execution unit configured to, in a case where it is determined that the waiting processes of the plurality of tasks to be processed do not end, obtain a second transaction to be processed from a first buffer in the shared memory, and start executing the second transaction.

In an embodiment, the predetermined memory includes a second buffer, and the recording unit is further configured to record, after processing the first transaction, in the second buffer, a first task to be processed corresponding to the first transaction in a case where it is determined that the second transaction is not submitted, where the second transaction is a transaction preceding the first transaction according to a predetermined submitting order.

In one embodiment, the determining unit is further configured to determine, based on the transaction that should be currently submitted and is recorded in the shared memory, whether a waiting process of the task to be processed corresponding to the smallest transaction number in the second buffer is finished, so as to determine whether the task to be processed with the end waiting process exists in the second buffer, where the transaction number corresponds to a submitting order of the transactions.

In one embodiment, the continuation execution unit is further configured to, in case it is determined that there is a second pending task in the second buffer waiting for an end of a procedure, continue to execute a commit of a third transaction based on execution information corresponding to the second pending task, wherein the second pending task corresponds to the third transaction.

In one embodiment, the predetermined memory includes a third buffer, the first transaction includes a read operation of the first variable, and the recording unit is further configured to record, after requesting the read of the first variable, a first task to be processed corresponding to the first transaction in the third buffer, where the first task to be processed includes a record of the first variable.

In an embodiment, the third buffer includes the second task to be processed, the second task to be processed corresponds to a read operation of a second variable in a second transaction, and the determining unit is further configured to determine whether a variable value of the second variable is returned, and in a case where it is determined that the variable value of the second variable is returned, determine that a waiting process of the second task to be processed is ended.

In one embodiment, for the plurality of tasks to be processed that have been recorded in the predetermined memory, the determining unit is further configured to sequentially determine, for the plurality of tasks to be processed that have been recorded in the third buffer, whether the waiting process of each task to be processed ends based on an order of from small to large corresponding to each task to be processed, where the second task to be processed is a task to be processed for which the waiting process determined for the first time ends, and the transaction number corresponds to a predetermined commit order of transactions.

In one embodiment, the determining unit is further configured to determine whether the variable value of the second variable is returned based on whether the variable value of the second variable is stored at a predetermined address, wherein the predetermined address corresponds to the first executable and the second transaction.

In one embodiment, the continuation execution unit is further configured to, in case it is determined that there is a second task to be processed waiting for an end of a process in the third buffer, continue executing the second transaction based on the execution information corresponding to the second task to be processed and the variable value of the second variable.

In one embodiment, the predetermined memory includes a fourth buffer, the first transaction includes a read operation for the first variable, and the recording unit is further configured to determine, after executing the code to the read operation, whether each transaction that is submitted before the first transaction and is not submitted is a conflicting transaction for which a write operation for the first variable has been executed, including a second transaction in each transaction, and in a case that it is determined that the second transaction is a conflicting transaction closest to the first transaction, record a first task to be processed corresponding to the first transaction in the fourth buffer, wherein the first task to be processed includes a record for the second transaction.

In one embodiment, the determining unit is further configured to determine, based on the transaction to be submitted currently recorded in the shared memory, whether there is a pending task waiting for the end of the procedure among the plurality of pending tasks recorded in the fourth buffer.

In an embodiment, a fifth buffer is included in the predetermined memory, the first transaction includes a read operation on the first variable, and the recording unit is further configured to infer whether each transaction that is submitted before the first transaction and is not submitted is a conflict transaction to be written to the first variable after executing the code to the read operation, the each transaction includes a second transaction, and in a case that the second transaction is inferred to be a conflict transaction closest to the first transaction, a first task to be processed corresponding to the first transaction is recorded in the fifth buffer, wherein the first task to be processed includes a record of the second transaction.

In an embodiment, the predetermined memory includes at least one buffer, where the at least one buffer corresponds to at least one task to be processed, and the determining unit is further configured to determine, based on a predetermined sequence of the at least one buffer, whether there is a task to be processed waiting for the end of the process in each buffer.

Another aspect of the present description provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform any of the methods described above.

Another aspect of the present specification provides a computing device comprising a memory and a processor, wherein the memory has executable code stored therein, and wherein the processor, when executing the executable code, performs any of the methods described above.

According to the scheme for concurrently executing the transaction, according to the embodiment of the specification, when waiting is needed in the process of executing the transaction by the executing body, the processing of the transaction is suspended, the processing information of the transaction is recorded, other tasks to be processed of the executing body are acquired from the buffer area to be processed, and after the waiting process is finished, the executing body continues to execute the transaction, so that the waiting time of the executing body is reduced, and the overall speed of concurrently executing the transaction is increased.

Drawings

The embodiments of the present specification may be further clarified by describing the embodiments of the present specification with reference to the accompanying drawings:

FIG. 1 illustrates a block chain system schematic diagram according to an embodiment of the present disclosure;

FIG. 2 illustrates a schematic diagram of concurrent execution of transactions by various nodes in a blockchain through multiple threads;

FIG. 3 illustrates a flow diagram of a method of concurrently executing transactions in a blockchain in accordance with an embodiment of the present description;

Fig. 4 illustrates an apparatus 400 for concurrently executing transactions in a blockchain in accordance with an embodiment of the present description.

Detailed Description

Embodiments of the present specification will be described below with reference to the accompanying drawings.

FIG. 1 illustrates a block chain system schematic diagram according to an embodiment of the present description. As shown in FIG. 1, the system includes a plurality of nodes (6 nodes are schematically shown) that form a blockchain, and the nodes are connected in pairs, including, for example, node 11, node 12, and node 13. As known to those skilled in the art, in a blockchain, some nodes collect multiple transactions in the blockchain and place them in a transaction pool and compete for accounting rights. For example node 11 in the figure becomes an accounting node by acquiring accounting rights. Node 11, after becoming an accounting node, will perform a number of transactions in its transaction pool and package the number of transactions into blocks for transmission to other nodes, e.g., to node 12. Node 12 will verify the block and similarly execute the transactions in the block. After a predetermined number of nodes verify the block, i.e., the block is in common, other nodes in the blockchain (e.g., node 13) will not need to continue to verify the block, but will directly execute transactions in the block to update the local relevant data.

FIG. 2 illustrates a schematic diagram of various nodes in a blockchain executing transactions concurrently through multiple threads. It will be appreciated that the threads may be replaced by executives of processes, coroutines, etc. As shown in fig. 2, in each node, generally, the number of CPUs is limited, the number of threads preset is also fixed, for example, assuming that the number of CPUs of the node is 4, the number of threads preset in the thread pool is 6, so that 6 threads compete for preempting the CPU, and the execution of tasks in the task pool can be started only after preempting the CPU.

In the process of concurrently executing multiple transactions by multiple threads, the computation of multiple variables may be involved in the multiple transactions, in the case that the same variables are not involved in two transactions, the execution sequence will not affect the final computation result, and in the case that the same variables are involved in two transactions, the execution sequence will affect the final computation result. In the embodiment of the present disclosure, in order to ensure that the execution results of multiple transactions by each node are the same, while multiple transactions are concurrently executed, conflicts between transactions on access variables are considered, so that some threads in threads executing in parallel need to go through a waiting process. Or need to wait while waiting for return access to storage.

As shown in fig. 2, the first node includes a shared memory, for example, a buffer 1 for indicating a transaction to be processed, which is readable and writable with respect to all threads. For example, 10 transactions 1,2, … to be processed are currently recorded in the first buffer, wherein the bit boxes corresponding to the numbers 1,2, …,10 in the figure should be all 1 initially, which indicates that the transactions are all transactions to be processed, and the numbers of the transactions 1 to 10 correspond to the submitting sequence of the respective transactions. After the concurrent execution of the transactions is started, for example, the threads 1 to 4 respectively preempt the CPUs 1 to 4, so that the threads 1 to 4 respectively acquire a task from the first buffer area for processing, for example, the threads 1 to 4 respectively start processing the transactions 1 to 4, and after the threads 1 to 4 start processing the transactions 1 to 4, respectively modify the bits corresponding to the transactions 1 to 4 in the first buffer area to 0 to indicate that the transactions have started to be executed. It will be appreciated that while thread 1 is schematically shown as preempting CPU1 and executing transaction 1, thread 2 is preempted to CPU2 and executing transaction 2, etc., it will be appreciated that the illustration is for purposes of illustration only and that the number of threads, CPU numbers, and transaction numbers do not correspond to each other, e.g., it is possible for thread 1 to preempt CPU2, execute transaction 3, etc.

Also shown in fig. 2 is a predetermined memory allocated only to thread 3, which may include a plurality of buffers therein, wherein each buffer corresponds to a waiting process. For example, four buffers in a predetermined memory are schematically shown in fig. 2, buffer 2-5, e.g., buffer 2 corresponds to a waiting process for executing a transaction waiting for commit, buffer 3 corresponds to a waiting process for requesting a read to wait for returning a variable value, buffer 4 corresponds to a waiting process for waiting for a previous transaction commit based on a variable write record prior to reading, and buffer 5 corresponds to a waiting process for waiting for a previous transaction commit or write prior to reading based on a probability of a transaction collision. In this embodiment of the present disclosure, in order to concurrently execute a transaction, the process of executing the transaction includes a process of processing the transaction and a process of submitting the transaction, where the process of processing the transaction stores a result of processing the transaction in a buffer corresponding to the transaction, and the process of submitting the transaction stores a final processing result in a shared memory shared by the transactions. For example, after thread 3 has processed transaction 3, in order to ensure that the final results of executing each transaction are consistent, it is necessary to ensure that each transaction is submitted sequentially in its numbered order, so transaction 3 needs to wait for the previous transaction 2 to be submitted before it is submitted. In this case, thread 3 records in buffer 2 the location corresponding to transaction 3, for example, changing the initial 0 to 1, and then thread 3 goes into buffer to acquire the new task. For example, thread 3 may first check buffer 2 for tasks waiting for the process to end. Also recorded in the shared memory of FIG. 2 is a current transaction window, which may be maintained, for example, by a thread that submitted the transaction. For example, thread 1 may modify the first transaction in the transaction window to 2 after transaction 1 is submitted. Whereby the transaction window is moved one bit back among the plurality of transactions to be submitted, the last transaction in the transaction window may be updated from 6 to 7 when the thread starts executing a new transaction (e.g., transaction 7) based on the window's first bit. At this point, for example, thread 3, after checking buffer 2, may first determine whether transaction 2 is a transaction that should currently be committed based on the window. In the case where there is no task waiting for the end of the process in the buffer 2, it is possible to check whether there is a task waiting for the end of the process in the buffer 3, and so on. In the case that no task is waiting for the end of the process in the buffers 2 to 5, a transaction to be processed, for example transaction 5, can be retrieved from the buffer 1. When thread 3 also encounters a waiting process during execution of transaction 5, a corresponding task to be processed will also be recorded in a corresponding one of buffers 2-5, e.g., thread 3 records the task to be processed corresponding to transaction 5 in buffer 4 as indicated by the right-hand dashed arrow in the figure. Thread 3 then similarly first determines in buffers 2-5 whether there are pending tasks waiting for the process to end. For example, when the thread 3 records a task to be processed corresponding to the transaction 3 in the buffer 2 during executing the transaction 3, the thread 3 determines whether the transaction 3 is a transaction to be submitted currently based on the window parameter in the shared memory, and when the left byte in the window displays "3", the task 3 is a transaction to be submitted currently, that is, the task to be processed corresponding to the transaction 3 recorded in the buffer 2 is a task waiting for ending the process. Thus, the thread 3 may acquire execution information of the transaction 3 in a buffer (not shown) storing the transaction execution information in a predetermined memory, and continue executing the transaction 3 based on the execution information.

It will be appreciated that the above description of fig. 2 is illustrative only and is not intended to limit the scope of the embodiments of the present description. For example, the specific form of the buffers 1 to 5 is not necessarily the form shown in the figure, as long as it can record the corresponding information. The process of concurrently executing the transactions described above will be described in detail below.

Fig. 3 is a flowchart of a method for concurrently executing transactions in a blockchain, the method being executed at a first node in the blockchain, the first node having a first executable preset therein, the first executable currently processing a first transaction, the method being executed by the first executable, according to one embodiment of the present disclosure, comprising:

Step S302, after performing a predetermined operation in the process of processing a first transaction, recording a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in a predetermined memory, so as to enter a waiting process relative to the first transaction, wherein the predetermined memory is only accessible by the first executing body;

Step S304, for a plurality of tasks to be processed which are already recorded in the preset memory, determining whether the tasks to be processed exist in which the waiting process is finished; and

In step S306, in the case where it is determined that the waiting process corresponding to the second task to be processed is ended, the second task to be processed is continuously executed based on the execution information corresponding to the second task to be processed, where the plurality of tasks to be processed includes the second task to be processed.

First, in step S302, after a predetermined operation is performed in the process of processing a first transaction, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed are recorded in a predetermined memory, so as to enter a waiting process with respect to the first transaction, wherein the predetermined memory is only accessible by the first executable.

As described above with reference to fig. 2, the first executable may be, for example, a thread, a process, a coroutine, or the like. Hereinafter, a thread will be described as an example.

In concurrently executing transactions in a node, multiple waiting processes may be included for one of the executing transactions, which may be due to different reasons.

In one embodiment, as described above with reference to FIG. 2, the plurality of concurrently executed transactions have been pre-set with a predetermined commit order, e.g., transactions 1-10 in FIG. 2 must be committed sequentially in their numbered order from smaller to larger, to ensure that the execution results of the plurality of transactions by the respective nodes are the same. Here, in the node, when a thread executes a transaction, the thread stores the processing result in a buffer corresponding to the transaction only, and after the thread submits the processing result, the thread stores the processing result in a shared memory shared by the transactions. For example, in the process of processing the first transaction, if a write operation is required for the first variable, the value of the first variable after the write operation is stored in the buffer corresponding to the first transaction only, and the value can be used only when the first transaction is processed, and the value is not read or written when other transactions are processed. After submitting the first transaction, the value of the first transaction is stored in the shared memory, which may be read by other transactions, or modified by the submitting.

Since each transaction has a predetermined order of submission, as shown in fig. 2, for example, the first transaction is transaction 5 in fig. 2, then the first executable is thread 3 in the figure. If thread 3 has not committed the transaction before transaction 5 after transaction 5 is processed, thread 3 needs to wait for transaction 4 to commit until transaction 5 is committed. Here, thread 3 may determine whether transaction 4 is committed based on a transaction window parameter preset in the shared memory. The maximum total number of concurrently executable transactions is controlled through the transaction window, and the transaction window is respectively provided with the transaction with the smallest number and the transaction with the largest number which are currently and concurrently executed, for example, 1 and 6 in fig. 2 indicate that the transactions which are currently and concurrently executed are transactions 1 to 6. By determining whether transaction 4 is the first transaction in the transaction window, it is determined whether transaction 4 should be currently submitted. In this case, as shown in fig. 2, the thread 3 may modify the bit corresponding to the transaction 5 in the buffer 2 in the predetermined memory corresponding to the thread 3 to 1 to add a task to be processed corresponding to the transaction 5, and the task to be processed may be continuously executed by the thread 3 only after the transaction 4 is submitted, and at the same time, the execution information corresponding to the task to be processed, that is, the current processing information of the transaction 5, may be stored in, for example, an execution information buffer corresponding to each transaction in the predetermined memory.

In one embodiment, transaction 5 includes a read operation on variable k1, and thread 3 issues a read request for variable k1 to the hardware or thread for reading the variable after starting the code to perform the read operation, after which "k1" is recorded in bytes corresponding to transaction 5, such as in buffer 3 in a predetermined memory corresponding to thread 3, shown in FIG. 2, to add a pending task corresponding to transaction 5 that may not be continued by thread 3 until the value of variable k1 returns.

In one embodiment, transaction 5 includes a read operation on variable k1, and thread 3, after beginning the code to perform the read operation, queries a write buffer in shared memory in which the current write to each variable (including variable k 1) during processing of each transaction is recorded. For example, the write buffer records only transaction 2 writing to variable k1, and does not record transactions 3 and 4 writing to variable k 1. Since transaction 2 will change the value of k1 in the variable table in shared memory after commit based on this record, transaction 5 needs to read the value of variable k1 after waiting for transaction 2 to commit, otherwise the wrong value of k1 will be read. After the thread 3 performs the query on the write buffer, a "2" is recorded in a byte corresponding to the transaction 5 in the buffer 3 in the predetermined memory corresponding to the thread 3 in fig. 2, so as to add a task to be processed corresponding to the transaction 5, where the "2" corresponds to the transaction 2, which means that the task to be processed can not be continuously executed by the thread 3 until the transaction 2 is submitted.

In one embodiment, a read operation on variable k1 is included in transaction 5. After beginning the code to perform the read operation, thread 3 infers whether each transaction (e.g., transactions 1-4 in FIG. 2) that is committed in sequence before transaction 5 among the plurality of transactions being concurrently performed is to write to variable k 1. In one method, transaction conflict probabilities of the variables may be determined in advance based on transaction execution histories in the node, when the transaction conflict probability of the variable k1 is greater than a predetermined threshold, it may be inferred that all transactions 1 to 4 are about to perform writing operation on the variable k1, so that after the transaction 4 is required to be submitted, reading operation in the transaction 5 is performed, and if the transaction 4 writes a writing value of the k1 into a buffer (the buffer is not a variable table corresponding to each transaction) corresponding to the transaction 4 in the shared memory during processing, reading of the k1 may be performed after the transaction 4 finishes writing the k 1. In one approach, thread 3 may determine the probability of collision of transaction 5 with each transaction preceding transaction 5 based on the transaction data of each transaction preceding transaction 5, and infer whether each transaction is about to write to k1 based on the probability of collision, thereby determining whether to wait for the transaction to commit or write. For example, in the case where it is determined that the probability of writing transaction 2 to k1 is equal to or greater than the predetermined threshold and the probabilities of writing transactions 3 to 4 to k1 are less than the predetermined threshold, "2" is recorded in the byte corresponding to transaction 5 in the buffer 5 in fig. 2 by the thread 3 to record a task to be executed corresponding to transaction 5, which can be continued to be executed by the thread 3 only after the transaction 2 commits or writes.

Although four wait cases are listed above, the wait cases in the embodiments of the present specification are not limited to the above four cases, but may be any wait case triggered by a predetermined operation.

In step S304, for a plurality of tasks to be processed already recorded in the predetermined memory, it is determined whether there is a task to be processed in which the waiting process ends.

As described above, the predetermined memory includes the buffers 2 to 5, in which different types of tasks to be processed are recorded, respectively. For example, after the thread 3 stores the first task to be processed corresponding to the transaction 5 in the predetermined memory through the above step S302, the thread 3 checks the buffers 2 to 5 in the predetermined memory in a predetermined order to acquire the task to be processed in which the waiting process ends. It will be appreciated that in fig. 2, the tasks to be processed in the buffers 2 to 5 are all tasks to be processed recorded by the thread 3.

For example, first, thread 3 may first check buffer 2. As described above, each task to be processed recorded in the buffer 2 corresponds to processing a transaction to be submitted for completion. For example, as shown in fig. 2, in the buffer 2, it may be determined that the minimum transaction with the corresponding bit of 1 is transaction 3, the thread 3 may determine whether the transaction that should be submitted currently is transaction 3 based on the transaction window in the shared memory, if the transaction that should be submitted currently is transaction 3, it indicates that the waiting process of the task to be processed corresponding to transaction 3 is finished, and if the task to be processed corresponding to transaction 3 is finished, the thread 3 may obtain the execution information corresponding to transaction 3 from the buffer for storing the execution information of the transaction in the predetermined memory, and continue to execute transaction 3 based on the execution information, that is, perform the submission of transaction 3.

In case thread 3 does not find a pending task in buffer 2 waiting for the end of the process, thread 3 may for example check buffer 3. As described above, each task to be processed recorded in the buffer 3 is waiting for the return of the corresponding magnitude of the strain. For example, if "k2" is recorded in the byte corresponding to transaction 3 in buffer 3, this indicates that transaction 3 is waiting for the return of the value of variable k 2. Thread 3 may determine whether the value of k2 has been written from a predetermined address corresponding to transaction 3, where the predetermined address corresponds to thread 3 and transaction 3, in the case where the value of k2 is written, then the waiting process for the task to be processed corresponding to transaction 3 ends. Wherein the value of k2 may be written at the address by the other thread performing the read operation, in which case the address may be, for example, an address writable by thread 3 and the other thread, or the value of k2 may be sent to thread 3 by the other thread performing the read operation and written at the address by thread 3, in which case the address is, for example, an address in a predetermined memory. In the event that it is determined that the value of k2 is not written, it may be determined for the task to be processed following transaction 3 whether the waiting process is over. For example, "k1" is recorded in the byte corresponding to transaction 5, then it may be determined whether the value of k1 has been written at a predetermined address corresponding to transaction 5.

In case thread 3 does not find a pending task in both buffers 2 and 3 waiting for the end of the process, thread 3 may for example check buffer 4. As described above, the task to be processed recorded in the buffer 4 corresponds to a transaction that waits for other transactions to commit for a read operation based on a write situation. Similar to checking buffer 2, thread 3 may determine, for example, whether transaction 1, which transaction 3 waits for, is committed based on the transaction window in the shared memory, and in the event that transaction 1 is determined to commit, the pending task corresponding to transaction 3 waits for the process to end.

In the case that thread 3 does not find a pending task waiting for the end of the process in buffers 2-4, thread 3 may, for example, check buffer 5. As described above, the tasks to be processed recorded in the buffer 5 correspond to transactions waiting for other transactions to commit or write for a read operation based on the probability of collision. Thread 3 may similarly determine whether transaction 1 waiting for transaction 3 is committed or whether the waiting process for the task to be processed corresponding to transaction 3 is complete based on the variable values written in shared memory by transaction 1 during processing.

It will be appreciated that the above-described predetermined memory includes buffers 2-5 which are merely illustrative and not limiting, and the above-described order of checking buffers is merely illustrative and not limiting, and in particular implementations, the buffers, and the order of checking buffers, may be set as needed for a scene.

In one embodiment, in the event that none of buffers 2-5 has checked for pending tasks waiting for the end of the process, thread 3 may check buffer 1 in shared memory as shown in FIG. 2, where pending transactions are recorded in buffer 1, so that thread 3 may obtain the lowest numbered pending transaction (e.g., transaction 6) from buffer 1 and begin executing the transaction.

In step S306, in the case where it is determined that the waiting process corresponding to the second task to be processed is ended, the second task to be processed is continuously executed based on the execution information corresponding to the second task to be processed, where the plurality of tasks to be processed includes the second task to be processed.

In one embodiment, if the thread 3 acquires the second task to be processed in the buffer 2, the thread 3 continues to execute the submission of the transaction corresponding to the second task to be processed based on the corresponding execution information. After determining that the waiting process of the second task to be processed is finished, the thread 3 removes the corresponding second task to be processed in the buffer, for example, modifies "1" corresponding to the second task to be processed in the buffer 2 to 0.

In one embodiment, thread 3 obtains a second task to be processed in buffer 3, and thread 3 continues to perform operations subsequent to the read-in-transaction operation based on the corresponding execution information and the corresponding variable values.

In one embodiment, thread 3 obtains a second task to be processed in buffer 4, and thread 3 continues to perform a corresponding read operation in a corresponding transaction based on the corresponding execution information.

In one embodiment, thread 3 obtains the second task to be processed in buffer 5, and thread 3 continues to perform the corresponding read operation in the corresponding transaction based on the corresponding execution information.

Fig. 4 illustrates an apparatus 400 for concurrently executing transactions in a blockchain, the apparatus deployed in a first executable of a first node in the blockchain, the first node having a first executable preset therein, the first executable currently processing a first transaction, according to an embodiment of the present disclosure, the apparatus comprising:

A recording unit 41 configured to record, after a predetermined operation is performed in a process of processing a first transaction, a first task to be processed corresponding to the first transaction, and execution information corresponding to the first task to be processed, in a predetermined memory, the predetermined memory being accessible only by the first executable, so as to enter a waiting process with respect to the first transaction;

a determining unit 42 configured to determine, for a plurality of tasks to be processed already recorded in the predetermined memory, whether there is a task to be processed in which a waiting process ends; and

And a continuing execution unit 43 configured to, in a case where it is determined that the waiting process corresponding to the second task to be processed ends, continue to execute the second task to be processed based on the execution information corresponding to the second task to be processed, where the plurality of tasks to be processed include the second task to be processed.

In an embodiment, the apparatus further comprises a transaction execution unit 44 configured to obtain a second transaction to be processed from the first buffer in the shared memory and to start executing the second transaction, in case it is determined that the waiting process of each of the plurality of tasks to be processed is not ended.

In one embodiment, the predetermined memory includes a second buffer, and the recording unit 41 is further configured to record, after processing the first transaction, a first task to be processed corresponding to the first transaction in the second buffer in a case where it is determined that the second transaction is not submitted, where the second transaction is a transaction preceding the first transaction according to a predetermined submitting order.

In one embodiment, the determining unit 42 is further configured to determine, based on the transaction that should be currently submitted and is recorded in the shared memory, whether the waiting process of the task to be processed corresponding to the smallest transaction number in the second buffer is finished, so as to determine whether the task to be processed with the end waiting process exists in the second buffer, where the transaction number corresponds to the submitting order of the transactions.

In an embodiment, the continuation execution unit 43 is further configured to, in case it is determined that there is a second pending task in the second buffer waiting for the end of the procedure, continue to execute the submission of a third transaction based on the execution information corresponding to the second pending task, wherein the second pending task corresponds to the third transaction.

In an embodiment, the predetermined memory includes a third buffer, the first transaction includes a read operation of the first variable, and the recording unit 41 is further configured to record, after requesting the read of the first variable, a first task to be processed corresponding to the first transaction in the third buffer, where the first task to be processed includes a record of the first variable.

In an embodiment, the third buffer includes the second task to be processed, where the second task to be processed corresponds to a read operation of a second variable in a second transaction, and the determining unit 42 is further configured to determine whether the variable value of the second variable is returned, and in a case where it is determined that the variable value of the second variable is returned, determine that the waiting process of the second task to be processed is ended.

In one embodiment, for the plurality of tasks to be processed that have been recorded in the predetermined memory, the determining unit 42 is further configured to sequentially determine, for the plurality of tasks to be processed that have been recorded in the third buffer, whether the waiting process of each task to be processed ends based on an order of from small to large corresponding to each task to be processed, where the second task to be processed is a task to be processed for which the waiting process determined for the first time ends, and the transaction number corresponds to a predetermined submitting order of the transactions.

In an embodiment, the determining unit 42 is further configured to determine whether the variable value of the second variable is returned based on whether the variable value of the second variable is stored at a predetermined address, wherein the predetermined address corresponds to the first executable and the second transaction.

In an embodiment, the continuation execution unit 43 is further configured to, in case it is determined that there is a second task to be processed waiting for the end of the procedure in the third buffer, continue to execute the second transaction based on the execution information corresponding to the second task to be processed and the variable value of the second variable.

In one embodiment, the predetermined memory includes a fourth buffer, the first transaction includes a read operation for the first variable, and the recording unit 41 is further configured to determine, after executing the code for the read operation, whether each transaction that is submitted before the first transaction and is not submitted is a conflicting transaction in which a write operation for the first variable has been executed, including a second transaction, and in a case where it is determined that the second transaction is a conflicting transaction closest to the first transaction, record a first task to be processed corresponding to the first transaction in the fourth buffer, where the first task to be processed includes a record for the second transaction.

In one embodiment, the determining unit 42 is further configured to determine whether there is a pending task waiting for the end of the procedure among the plurality of pending tasks recorded in the fourth buffer, based on the transaction that should be submitted currently recorded in the shared memory.

In an embodiment, a fifth buffer is included in the predetermined memory, the first transaction includes a read operation on the first variable, and the recording unit 41 is further configured to infer whether each transaction that is submitted before the first transaction and is not submitted is a conflict transaction to be performed on the first variable after executing the code to the read operation, wherein each transaction includes a second transaction, and in a case that the second transaction is inferred to be a conflict transaction closest to the first transaction, a first task to be processed corresponding to the first transaction is recorded in the fifth buffer, and wherein the first task to be processed includes a record of the second transaction.

In an embodiment, the predetermined memory includes at least one buffer, where the at least one buffer corresponds to at least one task to be processed, and the determining unit 42 is further configured to determine, based on a predetermined sequence of the at least one buffer, whether there is a task to be processed waiting for the end of the process in each buffer.

Another aspect of the present description provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform any of the methods described above.

Another aspect of the present specification provides a computing device comprising a memory and a processor, wherein the memory has executable code stored therein, and wherein the processor, when executing the executable code, performs any of the methods described above.

According to the scheme for concurrently executing the transaction, the processing of the transaction is suspended when waiting is needed in the process of executing the transaction by the executing body, other tasks to be processed of the executing body are acquired from the buffer area to be processed, and the executing body continues to execute the transaction after the waiting process is finished, so that the waiting time of the executing body is reduced, and the overall speed of concurrently executing the transaction is increased.

It should be understood that the description of "first," "second," etc. herein is merely for simplicity of description and does not have other limiting effect on the similar concepts.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Those of ordinary skill would further appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Those of ordinary skill in the art may implement the described functionality using different approaches for each particular application, but such implementation is not considered to be beyond the scope of the present application.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware, in a software module executed by a processor, or in a combination of the two. The software modules may be disposed in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

The foregoing description of the embodiments has been provided for the purpose of illustrating the general principles of the invention, and is not meant to limit the scope of the invention, but to limit the invention to the particular embodiments, and any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the invention are intended to be included within the scope of the invention.

Claims (24)

1. A method of concurrently executing transactions in a blockchain, the method being executed at a first node in the blockchain, comprising:

After a first executive body in the first node performs a preset operation in the process of processing a first transaction, recording a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in a preset memory, so as to enter a waiting process relative to the first transaction, wherein the preset memory is only accessible by the first executive body;

for a plurality of tasks to be processed which are already recorded in the preset memory, determining whether the tasks to be processed waiting for ending the process exist in the tasks to be processed; and

And continuing to execute a second to-be-processed task based on the execution information corresponding to the second to-be-processed task in the case that the waiting process corresponding to the second to-be-processed task in the plurality of to-be-processed tasks is determined to be ended.

2. The method of claim 1, further comprising, in the event that it is determined that none of the waiting processes for each of the plurality of pending tasks has ended, retrieving a second transaction to be processed from a first buffer in shared memory and beginning execution of the second transaction.

3. The method according to claim 1, wherein the predetermined memory includes a third buffer, the first transaction includes a read operation on a first variable, wherein after the predetermined operation is performed in the process of processing the first transaction, recording a first task to be processed corresponding to the first transaction in the predetermined memory, and the execution information corresponding to the first task to be processed includes recording the first task to be processed corresponding to the first transaction in the third buffer after the read of the first variable is requested, and wherein the first task to be processed includes the record of the first variable.

4. A method according to claim 3, wherein the third buffer includes the second task to be processed, the second task to be processed corresponding to a read operation of a second variable in a second transaction, and for a plurality of tasks to be processed that have been recorded in the predetermined memory, determining whether there is a task to be processed in which a waiting process ends includes determining whether a variable value of the second variable is returned, and in the case where it is determined that the variable value of the second variable is returned, determining that the waiting process of the second task to be processed ends.

5. The method of claim 4, wherein determining whether there is a waiting task for which a waiting process ends for a plurality of waiting tasks already recorded in the predetermined memory includes sequentially determining whether the waiting process of each waiting task ends based on an order in which transaction numbers corresponding to the respective waiting tasks are small to large for the plurality of waiting tasks already recorded in the third buffer, wherein the second waiting task is a waiting task for which the waiting process ends determined for the first time, wherein the transaction numbers correspond to a predetermined commit order of transactions.

6. The method of claim 4, wherein determining whether the variable value of the second variable is returned comprises determining whether the variable value of the second variable is returned based on whether the variable value of the second variable is stored at a predetermined address, wherein the predetermined address corresponds to the first executable and the second transaction.

7. The method according to claim 4, wherein, in a case where it is determined that the waiting process corresponding to the second task to be processed ends, continuing to execute the second task to be processed based on the execution information corresponding to the second task to be processed includes, in a case where it is determined that there is a second task to be processed in the third buffer that the waiting process ends, continuing to execute the second transaction based on the execution information corresponding to the second task to be processed and the variable value of the second variable.

8. The method according to claim 1, wherein the predetermined memory includes a fourth buffer, the first transaction includes a read operation for the first variable, wherein after the predetermined operation is performed during the processing of the first transaction, recording a first task to be processed corresponding to the first transaction in the predetermined memory, and execution information corresponding to the first task to be processed includes, after executing the code for the read operation, determining whether each transaction that is before the first transaction in the commit order and that is not committed is a conflicting transaction in which a write operation for the first variable has been performed, the each transaction including a second transaction, and in a case where the second transaction is determined to be a conflicting transaction closest to the first transaction, recording the first task to be processed corresponding to the first transaction in the fourth buffer, wherein the recording of the second transaction is included in the first task to be processed.

9. The method of claim 8, wherein determining whether there is a pending task waiting for an end of a process among the plurality of pending tasks recorded in the predetermined memory comprises determining whether there is a pending task waiting for an end of a process among the plurality of pending tasks recorded in the fourth buffer based on a transaction currently submitted recorded in a shared memory.

10. The method according to claim 1, wherein the predetermined memory includes a fifth buffer, the first transaction includes a read operation for a first variable, wherein after the predetermined operation is performed during the processing of the first transaction, recording a first task to be processed corresponding to the first transaction in the predetermined memory, and execution information corresponding to the first task to be processed includes, after executing the code for the read operation, deducing whether each transaction that is submitted before the first transaction and not submitted is a conflicting transaction to write the first variable, the each transaction including a second transaction, and in a case that the second transaction is deduced to be a conflicting transaction closest to the first transaction, recording the first task to be processed corresponding to the first transaction in the fifth buffer, wherein the recording of the second transaction is included in the first task to be processed.

11. The method of claim 1, wherein the predetermined memory includes at least one buffer corresponding to at least one task to be processed, and wherein determining whether there is a task to be processed waiting for the end of the process among the plurality of tasks to be processed already recorded in the predetermined memory includes determining whether there is a task to be processed waiting for the end of the process among the respective buffers based on a predetermined order of the at least one buffer.

12. An apparatus for concurrently executing transactions in a blockchain, the apparatus deployed in a first executable of a first node in the blockchain, the apparatus comprising:

A recording unit configured to record, in a predetermined memory, a first task to be processed corresponding to a first transaction and execution information corresponding to the first task to be processed after performing a predetermined operation in a process of processing the first transaction by a first executable in the first node, so as to enter a waiting process with respect to the first transaction, the predetermined memory being accessible only by the first executable;

a determining unit configured to determine, for a plurality of tasks to be processed that have been recorded in the predetermined memory, whether there is a task to be processed in which a waiting process ends; and

And a continuous execution unit configured to continue to execute a second to-be-processed task of the plurality of to-be-processed tasks based on the execution information corresponding to the second to-be-processed task in a case where it is determined that a waiting process corresponding to the second to-be-processed task is ended.

13. The apparatus according to claim 12, further comprising a transaction execution unit configured to, in case it is determined that none of the waiting processes of the plurality of tasks to be processed is completed, obtain a second transaction to be processed from a first buffer in the shared memory, and start executing the second transaction.

14. The apparatus according to claim 12, wherein the predetermined memory includes a third buffer, the first transaction includes a read operation of a first variable, and wherein the recording unit is further configured to record a first task to be processed corresponding to the first transaction in the third buffer after requesting the read of the first variable, wherein the first task to be processed includes a record of the first variable.

15. The apparatus according to claim 14, wherein the second task to be processed is included in the third buffer, the second task to be processed corresponds to a read operation of a second variable in a second transaction, the determining unit is further configured to determine whether a variable value of the second variable is returned, and in a case where it is determined that the variable value of the second variable is returned, determine that a waiting process of the second task to be processed ends.

16. The apparatus according to claim 15, wherein for the plurality of tasks to be processed that have been recorded in the predetermined memory, the determining unit is further configured to sequentially determine, for the plurality of tasks to be processed that have been recorded in the third buffer, whether or not a waiting process of each task to be processed ends based on an order in which transaction numbers corresponding to the respective tasks to be processed are small to large, wherein the second task to be processed is a task to be processed for which the waiting process determined for the first time ends, wherein the transaction numbers correspond to a predetermined commit order of transactions.

17. The apparatus of claim 15, wherein the determining unit is further configured to determine whether the variable value of the second variable is returned based on whether the variable value of the second variable is stored at a predetermined address, wherein the predetermined address corresponds to the first executable and the second transaction.

18. The apparatus of claim 15, wherein the continue execution unit is further configured to, in the event that it is determined that there is a second to-be-processed task in the third buffer waiting for a process to end, continue executing the second transaction based on execution information corresponding to the second to-be-processed task and a variable value of the second variable.

19. The apparatus according to claim 12, wherein the predetermined memory includes a fourth buffer, the first transaction includes a read operation for the first variable, wherein the recording unit is further configured to determine, after executing the code to the read operation, whether each transaction whose commit order is before the first transaction and whose non-commit is a conflicting transaction for which a write operation for the first variable has been executed, the each transaction including a second transaction, and in a case where the second transaction is determined to be a conflicting transaction closest to the first transaction, record a first task to be processed corresponding to the first transaction in the fourth buffer, wherein the first task to be processed includes a record of the second transaction.

20. The apparatus according to claim 19, wherein the determining unit is further configured to determine whether there is a pending task waiting for the end of the procedure among the plurality of pending tasks recorded in the fourth buffer, based on a transaction currently to be submitted recorded in the shared memory.

21. The apparatus according to claim 12, wherein a fifth buffer is included in the predetermined memory, a read operation for a first variable is included in the first transaction, wherein the recording unit is further configured to infer whether each transaction whose commit order is before the first transaction and which is not committed is a conflicting transaction to write the first variable after executing the code to the read operation, the each transaction including a second transaction, and in a case where it is inferred that the second transaction is a conflicting transaction closest to the first transaction, record a first task to be processed corresponding to the first transaction in the fifth buffer, wherein the first task to be processed includes a record of the second transaction.

22. The apparatus according to claim 12, wherein the predetermined memory includes at least one buffer, the at least one buffer corresponding to at least one task to be processed, respectively, and wherein the determining unit is further configured to determine whether there is a task to be processed waiting for the end of the process in each buffer based on a predetermined order of the at least one buffer.

23. A computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of any of claims 1-11.

24. A computing device comprising a memory and a processor, wherein the memory has executable code stored therein, which when executed by the processor, implements the method of any of claims 1-11.