WO2021036259A1

WO2021036259A1 - Method and device for executing transactions in parallel in blockchain

Info

Publication number: WO2021036259A1
Application number: PCT/CN2020/082696
Authority: WO
Inventors: 刘晓建; 张兆勇
Original assignee: 创新先进技术有限公司
Priority date: 2019-08-30
Filing date: 2020-04-01
Publication date: 2021-03-04
Also published as: TWI732501B; CN110689344A; CN110689344B; CN113435885A; TW202109512A

Abstract

A method and device for executing transactions in parallel in a blockchain. The method is executed by a first executor in a first node in a blockchain, and comprises: after performing a predetermined operation during processing of a first transaction, recording, in a shared memory, a first pending task corresponding to the first transaction and execution information corresponding to the first pending task, and placing the first transaction in a waiting process (S302); determining, from multiple pending tasks already recorded in the shared memory, whether or not a pending task that has completed a waiting process is present, wherein the multiple pending tasks are recorded by a predetermined number of executors (S304); and if it is determined that a waiting process corresponding to a second pending task is over, executing the second pending task on the basis of execution information corresponding to the second pending task, wherein the multiple pending tasks comprise the second pending task (S306).

Description

Method and device for concurrently executing transactions in blockchain

Technical field

The embodiments of this specification relate to the field of blockchain technology, and more specifically, to a method and device for concurrently executing transactions in a blockchain.

Background technique

Blockchain technology is built on a peer-to-peer (P2P) network. It uses a chained data structure to verify and store data, uses a distributed node consensus algorithm to generate and update data, and uses cryptography to ensure the security of data transmission and access. A new distributed infrastructure and computing paradigm that uses smart contracts composed of automated script codes to program and manipulate data. Blockchain technology, also known as distributed ledger technology, is a decentralized distributed database technology, which is characterized by decentralization, openness and transparency, non-tampering, and trustworthiness. Every piece of data in the blockchain will be broadcast to the blockchain nodes of the entire network, and each full node has a full amount of consistent data. The nodes in the blockchain conduct transactions such as transfers and deposit data by sending transactions. The accounting nodes in the blockchain collect transactions in the blockchain in the transaction pool, execute the transactions, and execute the transactions After that, these transactions are packaged into blocks and spread to the blockchain. The verification node in the blockchain will verify the block sent from the accounting node. After the verification is passed, each node will execute each transaction included in the block when it receives the block. In order to ensure the data consistency of each node, when multiple transactions in the block are executed in each node, the order of submission of the multiple transactions needs to be consistent, so that consistent execution results can be obtained. Therefore, in the prior art, before executing the transaction, the accounting node will number multiple transactions to be executed according to predetermined rules, and execute multiple transactions in sequence in the order of the numbers, that is, submit multiple transactions in turn, and other After receiving the block, the node also executes and submits the multiple transactions in sequence according to the above-mentioned transaction number sequence. However, the multiple transactions are not necessarily mutually dependent. In the case where there is no dependency between the two transactions, concurrent execution of the two transactions does not affect the final result. And if there are dependencies between two transactions executed concurrently, the concurrent execution will affect the final result.

Therefore, there is a need for a more effective method of concurrently executing multiple transactions in the blockchain.

Summary of the invention

The embodiments of this specification aim to provide a more effective solution for concurrently executing transactions to solve the deficiencies in the prior art.

In order to achieve the above objective, one aspect of this specification provides a method for concurrently executing transactions in a blockchain. The method is executed on a first node in the blockchain. The first node currently passes a preset predetermined number of transactions. The executive body executes transactions concurrently, including a first executive body, which is currently processing a first transaction, and the method is executed by the first executive body, including:

After a predetermined operation is performed in the process of processing the first transaction, the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task are recorded in the shared memory so as to be relative to the first to-be-processed task. The transaction enters the waiting process;

For the multiple pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process, and the multiple pending tasks are recorded by the predetermined number of executives; and

In the case where it is determined that the waiting process corresponding to the second to-be-processed task ends, the second to-be-processed task is continued to be executed based on the execution information corresponding to the second to-be-processed task, wherein the multiple to-be-processed tasks include The second task to be processed.

In one embodiment, the method further includes, in a case where it is determined that the waiting processes of the multiple to-be-processed tasks are not finished, obtaining the second transaction to be processed from the first buffer in the shared memory, and Start the execution of the second transaction.

In one embodiment, the shared memory includes a second buffer area, wherein, after a predetermined operation is performed in the process of processing the first transaction, the first to-be-processed task corresponding to the first transaction and the first to-be-processed task corresponding to the first transaction are recorded in the shared memory, and The execution information corresponding to the first task to be processed includes, after processing the first transaction, in the case where it is determined that the second transaction has not been submitted, the first task to be processed corresponding to the first transaction is recorded in the second buffer. A processing task, wherein the second transaction is the previous transaction of the first transaction according to a predetermined submission order.

In one embodiment, for the multiple pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process includes: determining the first transaction based on the current transaction that should be submitted recorded in the shared memory Whether the waiting process of the pending task corresponding to the smallest transaction number in the second buffer zone is over, to determine whether there is a pending task waiting for the end of the process in the second buffer zone, wherein the transaction number corresponds to the transaction submission sequence .

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

In one embodiment, the shared memory includes a third buffer, and the first transaction includes a read operation of the first variable, wherein, after a predetermined operation is performed in the process of processing the first transaction, the shared memory Recording in the memory the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task includes, after requesting the reading of the first variable, in the third buffer The first task to be processed corresponding to the first transaction is recorded, wherein the first task to be processed includes a record of the first variable.

In an embodiment, the third buffer includes the second to-be-processed task, and the second to-be-processed task corresponds to the read operation of the second variable in the second transaction. For the shared memory To determine whether there is a pending task waiting for the end of the process includes multiple pending tasks that have been recorded in, determining whether the variable value of the second variable is returned, and determining whether the variable value of the second variable is returned , It is determined that the waiting process of the second to-be-processed task ends.

In one embodiment, for the multiple pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process includes: for multiple pending tasks that have been recorded in the third buffer , Based on the descending order of the transaction number corresponding to each task to be processed, determine in turn whether the waiting process of each task to be processed is over, wherein the second task to be processed is the first determined task to be processed after the waiting process ends, where , The transaction number corresponds to the predetermined submission sequence of the transaction.

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 in the shared memory , Wherein the predetermined address corresponds to the second transaction.

In one embodiment, in a case where it is determined that the waiting process corresponding to the second to-be-processed task is over, based on the execution information corresponding to the second to-be-processed task, continuing to execute the second to-be-processed task includes: When there is a second task to be processed waiting for the process to end in the third buffer, the second transaction is continued to be executed 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 shared memory includes a fourth buffer, the first transaction includes a read operation of the first variable, wherein, after a predetermined operation is performed in the process of processing the first transaction, the shared memory Recording the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task in the memory includes, after executing the code of the read operation, determining that the submission sequence is before the first transaction, And whether each transaction that has not been submitted is a conflict transaction in which the write operation to the first variable has been performed, and the each transaction includes a second transaction, in the case of determining that the second transaction is the closest conflict transaction to the first transaction In the fourth buffer zone, the first task to be processed corresponding to the first transaction is recorded, wherein the first task to be processed includes the record of the second transaction.

In one embodiment, for the multiple pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process includes: determining whether there is a transaction that should be submitted currently recorded in the shared memory Whether there is a to-be-processed task waiting for the end of the process among the multiple to-be-processed tasks recorded in the fourth buffer.

In one embodiment, the shared memory includes a fifth buffer, and the first transaction includes a read operation of the first variable, wherein, after a predetermined operation is performed in the process of processing the first transaction, the shared memory Recording the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task in the memory includes, after executing the code of the read operation, inferring that the order of submission is before the first transaction, And whether each transaction that has not been submitted is a conflict transaction that is about to write the first variable, and each transaction includes a second transaction. In the case of inferring that the second transaction is the closest conflict transaction to the first transaction, The first task to be processed corresponding to the first transaction is recorded in the fifth buffer zone, wherein the first task to be processed includes a record of the second transaction.

In one embodiment, the shared memory includes at least one buffer, and the at least one buffer corresponds to at least one task to be processed respectively, wherein, for multiple tasks to be processed that have been recorded in the shared memory, Determining whether there are pending tasks waiting for the end of the process includes determining whether there are pending tasks waiting for the end of the process in each buffer based on a predetermined sequence of the at least one buffer.

Another aspect of this specification provides a device for concurrently executing transactions in a blockchain. The device is deployed in a first executor in a first node in the blockchain. A predetermined number of executive bodies concurrently execute transactions, including a first executive body, which is currently processing the first transaction, and the device includes:

The recording unit is configured to record, in the shared memory, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed after a predetermined operation is performed in the process of processing the first transaction, to Enter the waiting process with respect to the first transaction;

The determining unit is configured to determine whether there is a pending task waiting for the end of the process among the multiple pending tasks that have been recorded in the shared memory, and the multiple pending tasks are recorded by the predetermined number of executives; as well as

The continuing execution unit is configured to continue to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task in a case where it is determined that the waiting process corresponding to the second to-be-processed task is over, wherein the The multiple to-be-processed tasks include the second to-be-processed task.

In an embodiment, the device further includes a transaction execution unit configured to, in a case where it is determined that the waiting processes of the multiple pending tasks are not finished, obtain the pending tasks from the first buffer in the shared memory. Process the second transaction, and start execution of the second transaction.

In one embodiment, the shared memory includes a second buffer area, wherein the recording unit is further configured to, after processing the first transaction, in a case where it is determined that the second transaction has not been submitted, in the first transaction The first to-be-processed task corresponding to the first transaction is recorded in the second buffer zone, wherein the second transaction is the previous transaction of the first transaction according to a predetermined submission sequence.

In an embodiment, the determining unit is further configured to determine whether the waiting process of the task to be processed corresponding to the smallest transaction number in the second buffer is over based on the transaction currently to be submitted recorded in the shared memory, to It is determined whether there is a task to be processed waiting for the end of the process in the second buffer zone, wherein the transaction number corresponds to the submission sequence of the transaction.

In an embodiment, the continuing execution unit is further configured to, in a case where it is determined that the waiting process of the second to-be-processed task in the second buffer is over, based on the execution corresponding to the second to-be-processed task Information, continue to perform the submission of the third transaction, wherein the second pending task corresponds to the third transaction.

In an embodiment, the shared memory includes a third buffer, and the first transaction includes a read operation of the first variable, wherein the recording unit is further configured to request the first variable After the variable is read, the first to-be-processed task corresponding to the first transaction is recorded in the third buffer, wherein the first to-be-processed task includes a record of the first variable.

In an embodiment, the third buffer includes the second to-be-processed task, the second to-be-processed task corresponds to a reading operation of the second variable in the second transaction, and the determining unit further It is 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, it is determined that the waiting process of the second to-be-processed task ends.

In one embodiment, the determining unit is further configured to, for a plurality of pending tasks that have been recorded in the third buffer, determine each pending task in sequence based on the order of the transaction number corresponding to each pending task from small to large. Whether the waiting process of the processing task ends, wherein the second task to be processed is the first determined task to be processed after the waiting process ends, and the transaction number corresponds to the predetermined submission sequence of the transaction.

In an 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 in the shared memory, wherein the predetermined The address corresponds to the second transaction.

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

In one embodiment, the shared memory includes a fourth buffer area, wherein the recording unit is further configured to, after executing the code of the read operation, determine that the submission sequence is before the first transaction and is not Whether each submitted transaction is a conflict transaction in which a write operation to the first variable has been performed, and each transaction includes a second transaction. In the case of determining that the second transaction is the closest conflict transaction to the first transaction, The first to-be-processed task corresponding to the first transaction is recorded in the fourth buffer zone, wherein the first to-be-processed task includes a record of the second transaction.

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

In one embodiment, the shared memory includes a fifth buffer, and the first transaction includes a read operation of the first variable, wherein the recording unit is further configured to: After operating the code, it is inferred whether each transaction whose submission sequence is before the first transaction and is not submitted is a conflict transaction that will write the first variable. The each transaction includes a second transaction, and the second transaction is inferred. In the case where the transaction is a conflicting transaction closest to the first transaction, the first pending task corresponding to the first transaction is recorded in the fifth buffer, wherein the first pending task includes a second transaction record of.

In an embodiment, the shared memory includes at least one buffer, and the at least one buffer corresponds to at least one task to be processed, wherein the determining unit is further configured to, based on the at least one buffer To determine whether there are pending tasks waiting for the end of the process in each buffer.

Another aspect of this specification provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to perform any of the above methods.

Another aspect of this specification provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, any one of the above methods is implemented.

Through the solution of concurrently executing transactions according to the embodiments of this specification, the processing information of the transaction is recorded when the execution body needs to wait while executing the transaction, and other pending tasks or other pending transactions are obtained from the shared memory for processing, thereby It reduces the waiting time of the execution body and speeds up the overall speed of concurrent execution of transactions.

Description of the drawings

By describing the embodiments of this specification in conjunction with the accompanying drawings, the embodiments of this specification can be made clearer:

Fig. 1 shows a schematic diagram of a blockchain system according to an embodiment of the present specification;

Figure 2 shows a schematic diagram of each node in the blockchain executing transactions concurrently through multiple threads;

Fig. 3 shows a flowchart of a method for concurrently executing transactions in a blockchain according to an embodiment of the present specification;

Fig. 4 shows a device 400 for concurrently executing transactions in a blockchain according to an embodiment of the present specification.

detailed description

The embodiments of this specification will be described below in conjunction with the drawings.

Fig. 1 shows a schematic diagram of a blockchain system according to an embodiment of the present specification. As shown in FIG. 1, the system includes multiple nodes (six nodes are schematically shown in the figure) constituting a blockchain, and these nodes are connected in pairs, including node 11, node 12, and node 13, for example. As those skilled in the art know, in the blockchain, some nodes collect multiple transactions in the blockchain and put them into the transaction pool and compete for the right to keep accounts. For example, the node 11 in the figure becomes a billing node by acquiring the billing right. After node 11 becomes an accounting node, it will execute multiple transactions in its transaction pool, package the multiple transactions into blocks and send them to other nodes, for example, to node 12. The node 12 will verify the block and execute multiple transactions in the block in the same way. After a predetermined number of nodes verify the block, that is, a consensus on the block is reached, other nodes in the blockchain (such as node 13) will not need to continue to verify the block, but directly The transactions in this block are executed to update local related data.

Figure 2 shows a schematic diagram of each node in the blockchain executing transactions concurrently through multiple threads. It can be understood that the thread can also be replaced by an execution body such as a process and a coroutine. As shown in Figure 2, in each node, usually, the number of CPUs is limited, and the number of preset threads is also fixed. For example, assuming that the number of CPUs of the node is 4, the number of CPUs preset in the thread pool is The number of threads is 6, so that 6 threads compete to preempt the CPU, and only after the CPU is preempted, can the tasks in the task pool begin to be executed.

In the process of concurrent execution of multiple transactions by multiple threads, the calculation of multiple variables may be involved in the multiple transactions. In the case that the same variables are not involved in the two transactions, the order of execution will not affect The final calculation result, and in the case of two transactions involving the same variables, the order of execution will affect the final calculation result. In the embodiments of this specification, in order to ensure that the execution results of multiple transactions by each node are the same, while multiple transactions are executed concurrently, the conflicts of access variables between transactions are considered, so that some of the threads executed in parallel are The thread needs to go through a waiting process. Or you need to wait while waiting to return to access storage.

As shown in FIG. 2, the graph includes the shared memory of the first node. The shared memory includes, for example, a buffer 1 for indicating transactions to be processed. The shared memory is readable and writable with respect to all threads. For example, there are currently 10 pending

transactions

1, 2,...10 recorded in the first buffer. The bit boxes corresponding to the

numbers

1, 2,..., 10 in the figure should all be 1, indicating that they are all It is a transaction to be processed, where the serial number of transaction 1-10 corresponds to the order of submission of each transaction. After starting to execute transactions concurrently, for example, threads 1 to 4 preempt CPUs 1 to 4, respectively, so that threads 1 to 4 can respectively obtain a task from the first buffer for processing, for example, threads 1 to 4 start processing transactions respectively 1 to 4. After threads 1 to 4 start to process transactions 1 to 4, they respectively modify the corresponding bits of transactions 1 to 4 in the first buffer to 0 to indicate that these transactions have been executed. It can be understood that although the figure schematically shows that thread 1 preempts CPU1 and executes transaction 1, thread 2 preempts CPU2 and executes transaction 2, etc., it can be understood that the content shown in the figure is only for illustrative purposes. The number, CPU number, and transaction number do not correspond to each other. For example, thread 1 may preempt CPU2, execute transaction 3, and so on.

Figure 2 also shows multiple buffers for recording tasks to be processed, buffers 2 to 5, where each buffer corresponds to a waiting process. For example, buffer 2 corresponds to the waiting process of waiting for submission after the transaction is executed, buffer 3 corresponds to the waiting process of requesting a read to wait for the return variable value, and buffer 4 corresponds to the waiting process of writing records based on variables before reading. The waiting process of the previous transaction submission corresponds to the buffer 5 corresponding to the waiting process of waiting for the previous transaction submission or writing based on the transaction conflict probability before reading. In the embodiment of this specification, in order to execute the transaction concurrently, the process of executing the transaction includes the process of processing the transaction and the process of submitting the transaction. The process of processing the transaction is to store the result of the transaction in the buffer corresponding to the transaction. In the process of submitting a transaction, the final processing result is stored in the shared memory shared by each transaction. 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 in the order of its number. Therefore, transaction 3 needs to wait for the previous transaction 2 to submit before submitting. In this case, thread 3 records the position corresponding to transaction 3 in buffer 2, for example, changing the initial 0 to 1, and then thread 3 goes to the buffer to obtain a new task. For example, thread 3 may first check whether there are tasks in buffer 2 waiting for the end of the process. The shared memory in FIG. 2 also records the current transaction window, and the current transaction window can be maintained by the thread that submitted the transaction, for example. For example, after thread 1 submits transaction 1, the first transaction in the transaction window can be modified to 2. Therefore, the transaction window moves one position backward among the multiple transactions to be submitted. When the thread starts to execute a new transaction (for example, transaction 7) according to the first position of the window, the last transaction in the transaction window can be updated from 6 to 7. At this time, for example, after the thread 3 checks the buffer 2, it may first determine whether the transaction 2 is a transaction that should be submitted currently based on the window. In the case that there is no task waiting for the end of the process in the buffer 2, it can be checked whether there is a task waiting for the end of the process in the buffer 3, and so on. In the case that there is no task waiting for the end of the process in buffers 2 to 5, the transaction to be processed can be obtained from buffer 1, for example, transaction 6. When thread 3 also encounters a waiting process in the process of executing transaction 6, it will also record the corresponding pending task in the corresponding one of buffers 2 to 5, for example, as shown by the dotted arrow on the right side of the figure , Thread 3 records the pending tasks corresponding to transaction 6 in buffer 4. Then, similarly, thread 3 first determines in buffers 2 to 5 whether there are pending tasks waiting for the end of the process.

It can be understood that the above description of FIG. 2 is only schematic, and is not used to limit the scope of the embodiments of the present specification. For example, the specific forms of the buffers 1 to 5 are not necessarily the forms shown in the figure, as long as they can record corresponding information. Hereinafter, the process of concurrently executing transactions according to the embodiments of the present specification will be described in detail.

Figure 3 shows a flow chart of a method for concurrently executing transactions in a blockchain according to an embodiment of the present specification. The method is executed on a first node in the blockchain, and the first node is preset with a first node. An executive body, the first executive body is currently processing a first transaction, and the method is executed by the first executive body, including:

Step S302: After a predetermined operation is performed in the process of processing the first transaction, the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task are recorded in the shared memory, so as to compare all The first transaction enters the waiting process;

Step S304, for the multiple pending tasks that have been recorded in the shared memory, it is determined whether there are pending tasks waiting for the end of the process; and

Step S306: In the case where it is determined that the waiting process corresponding to the second to-be-processed task is over, continue to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task, wherein the plurality of to-be-processed tasks The tasks include the second to-be-processed task.

First, in step S302, after a predetermined operation is performed in the process of processing the first transaction, the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task are recorded in the shared memory to Enter the waiting process with respect to the first transaction.

As described above with reference to FIG. 2, the first executive body may be, for example, an executive body such as a thread, a process, or a coroutine, and the shared memory is shared with respect to multiple executive bodies used to execute transactions concurrently. In the following, thread will be used as an example.

In the process of concurrently executing transactions in nodes, for one of the transactions being executed, multiple waiting processes may be included, and the waiting processes may be caused by different reasons.

In one embodiment, as described above with reference to Figure 2, the multiple concurrently executed transactions have preset a predetermined submission order. For example, transactions 1 to 10 in Figure 2 must be numbered from small to large. Submit in order to ensure that the execution results of the multiple transactions by each node are the same. Here, in the node, when the thread executes the transaction, the processing result is first saved in the buffer corresponding to the transaction, and after submission, the execution result is saved in the shared memory shared by each transaction. For example, in the process of processing the first transaction, the first variable needs to be written, and the value of the first variable after the write operation is first saved in the buffer corresponding to only the first transaction. It can be used in the first transaction, and the value will not be read or written when processing other transactions. After the first transaction is submitted, the value of the first transaction is stored in the shared memory, and other transactions can also read the value or modify the value by submitting it.

Since each transaction has a predetermined submission sequence, as shown in FIG. 2, for example, the first transaction is transaction 6 in FIG. 2, and the first executive body is thread 3 in the figure. If thread 3 finishes processing transaction 6 and the transaction before transaction 6 has not been submitted, at this time, thread 3 needs to wait for the completion of transaction 5 submission before submitting transaction 6. Here, the thread 3 may determine whether the transaction 5 is submitted based on the preset transaction window parameters in the shared memory. The transaction window controls the maximum total number of transactions that can be executed concurrently. The two sides of the transaction window are the transaction with the smallest number and the transaction with the largest number that are currently executed concurrently. For example, 1 and 6 in Figure 2 represent the current concurrently executed transactions. For transactions 1～6. Thus, by determining whether transaction 5 is the smallest transaction in the transaction window, it is determined whether transaction 5 should be submitted currently. In this case, thread 3 can modify the bit corresponding to transaction 6 in buffer 2 to 1, as shown in Figure 2, to add a pending task corresponding to transaction 6, which can only wait until the transaction 5 After submission, execution can continue. At the same time, the execution information corresponding to the task to be processed, that is, the current processing information of transaction 6, can be stored in the shared memory, for example, in the execution information buffer corresponding to each transaction.

In one embodiment, transaction 6 includes a read operation on variable k1, and thread 3 sends a read request for variable k1 to the hardware or thread used to read the variable after starting to execute the code for the read operation. Then record "k1" in the byte corresponding to transaction 6 in the buffer 3 shown in Figure 2 to add a pending task corresponding to transaction 6, and the pending task waits until the value of the variable k1 returns Before continuing.

In one embodiment, transaction 6 includes a read operation on variable k1. After thread 3 starts to execute the code for the read operation, it queries the write buffer in the shared memory, and the write buffer records the current The writing status of each variable (including variable k1) during the processing of each transaction. For example, the write buffer only records that transaction 4 writes to variable k1, and transaction 5 writes to variable k1 is not recorded. Because, based on this record, transaction 4 will change the value of k1 in the variable table in the shared memory after submission, therefore, transaction 6 needs to wait for transaction 4 to submit before reading the value of the variable k1, otherwise it will read the error The value of k1. After thread 3 checks the write buffer, it records "4" in the byte corresponding to transaction 6 in buffer 3 in Figure 2 to add a pending task corresponding to transaction 6, so The "4" corresponds to transaction 4, which means that the pending task can only be executed after transaction 4 is submitted.

In one embodiment, transaction 6 includes a read operation on variable k1. After thread 3 starts to execute the code for the read operation, it infers whether each transaction (for example, transactions 1 to 5 in Figure 2) that is submitted in the order of submission before transaction 6 among multiple transactions being executed concurrently will write to variable k1 . In one method, the transaction conflict probability of each variable can be determined in advance based on the transaction execution history in the node. When the transaction conflict probability of variable k1 is greater than a predetermined threshold, it can be inferred that transactions 1 to 5 will be performed on variable k1. Write operation. Therefore, after transaction 5 is submitted, the read operation in transaction 6 should be performed. If transaction 5 writes the value written to k1 into the buffer corresponding to transaction 5 in the shared memory during processing (the If the buffer is not in the variable table corresponding to each transaction), then after transaction 5 finishes writing to k1, read k1. In one method, thread 3 can determine the conflict probability between transaction 6 and each previous transaction based on the transaction data of each transaction before transaction 6, and based on the conflict probability, infer whether each transaction will write k1, thereby Determine whether to wait for the submission or writing of the transaction. For example, in the case where it is determined that the write probability of transaction 4 to k1 is greater than or equal to a predetermined threshold, and the write probability of transaction 5 to k1 is less than the predetermined threshold, thread 3 in the buffer 5 in FIG. 2 corresponds to the word of transaction 6 Record "4" in the section to record a task to be executed corresponding to transaction 6. The task to be executed can only be executed after transaction 4 is submitted or written.

Although four waiting conditions are listed above, the waiting conditions in the embodiments of this specification are not limited to the above four conditions, but may be any waiting conditions triggered by a predetermined operation.

In step S304, for the multiple pending tasks that have been recorded in the shared memory, it is determined whether there are pending tasks waiting for the end of the process.

As described above, the shared memory includes buffers 2 to 5, in which different types of pending tasks are recorded respectively. For example, after thread 3 stores the first pending task corresponding to transaction 6 in the shared memory through the above step S302, thread 3 checks the buffers 2 to 5 in the shared memory in a predetermined order to obtain the waiting The pending task at the end of the process. It can be understood that, in FIG. 2, the tasks to be processed in the buffers 2 to 5 may be tasks to be processed recorded by any of the threads 1 to 4.

For example, first, thread 3 may check buffer 2 first. As described above, each pending task recorded in the buffer 2 corresponds to a transaction that has been processed and is waiting to be submitted. For example, as shown in Figure 2, in buffer 2, the smallest transaction with a corresponding bit of 1 can be determined as transaction 2, and thread 3 can determine whether the transaction that should be submitted is transaction 2 based on the transaction window in the shared memory. The transaction that should be submitted is transaction 2, which means that the waiting process of the pending task corresponding to transaction 2 is over. Thread 3 can obtain the execution information corresponding to transaction 2 from the buffer for storing transaction execution information in the shared memory. And continue to execute transaction 2 based on the execution information, that is, submit the transaction 2.

In the case that the thread 3 does not find a pending task waiting for the end of the process in the buffer 2, the thread 3 may check the buffer 3, for example. As mentioned above, each pending task recorded in the buffer 3 is waiting for the return of the corresponding variable value. For example, if "k2" is recorded in the byte corresponding to transaction 2 in buffer 3, it means that transaction 2 is waiting for the return of the value of variable k2. Thread 3 can determine whether the value of k2 has been written from the predetermined address in the shared memory corresponding to transaction 2. When the value of k2 is written, it indicates the waiting process of the pending task corresponding to transaction 2 End, wherein the predetermined address corresponds to the transaction 2. Among them, the value of k2 can be written at this address by other threads performing read operations. In the case where it is determined that the value of k2 has not been written, it can be determined whether the waiting process is over for the tasks to be processed after transaction 2. For example, if "k1" is recorded in the byte corresponding to transaction 3, it can be determined whether the value of k1 has been written in the predetermined address corresponding to transaction 3.

In the case that thread 3 does not find a pending task waiting for the end of the process in both

buffers

2 and 3, thread 3 may check buffer 4, for example. As described above, the pending tasks recorded in the buffer 4 correspond to transactions that wait for other transactions to be submitted for read operations based on write conditions. Similar to checking buffer 2, thread 3 can determine whether transaction 1 waiting for transaction 2 is submitted based on the transaction window in shared memory. In the case where transaction 1 is determined to be submitted, the pending task corresponding to transaction 2 is waiting The process is over. In the case where it is determined that the transaction 1 has not been submitted, the thread 3 can determine whether the waiting process of the task to be processed corresponding to the transaction after the transaction 2 has ended, for example, it can determine whether the waiting process corresponding to the transaction 3 has ended.

In the case that the thread 3 does not find any pending tasks waiting for the end of the process in the buffers 2 to 4, the thread 3 may check the buffer 5, for example. As described above, the pending tasks recorded in the buffer 5 correspond to transactions waiting for other transactions to be submitted or written for read operations based on the conflict probability. The thread 3 can similarly determine whether the transaction 1 waiting for the transaction 2 is submitted, or can determine whether the waiting process of the pending task corresponding to the transaction 2 is over based on the variable value written in the shared memory during the processing of the transaction 1 or not.

It can be understood that the buffers 2 to 5 included in the shared memory are only illustrative and not restrictive, and the sequence of checking the buffers is only illustrative and not restrictive. In specific implementation, it can be based on The scene needs to set up the buffer and check the order of the buffer.

In one embodiment, in the case that no pending task waiting for the end of the process is checked in the buffers 2 to 5, the thread 3 may check the buffer 1 in the shared memory shown in FIG. 2, and the buffer 1 The transaction to be processed is recorded in, so that the thread 3 can obtain the transaction to be processed with the smallest number (for example, transaction 6) from the buffer 1, and start to execute the transaction.

In step S306, in the case where it is determined that there is a second to-be-processed task waiting for the end of the process in the shared memory, continue to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task.

In one embodiment, the thread 3 obtains the second to-be-processed task whose waiting process ends in the buffer 2, and then the thread 3 continues to execute the submission of the transaction corresponding to the second to-be-processed task based on the corresponding execution information. After the thread 3 determines that the waiting process of the second to-be-processed task ends, it removes the corresponding second to-be-processed task in the buffer, for example, changes the “1” corresponding to the second to-be-processed task in the buffer 2 to 0.

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

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

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

FIG. 4 shows another aspect of this specification according to an embodiment of the specification provides a device 400 for concurrently executing transactions in a blockchain, the device being deployed in the first execution body of the first node in the blockchain In the first node, the transaction is currently executed concurrently through a preset predetermined number of executive bodies, including a first executive body, and the first executive body is currently processing a first transaction, and the device includes:

The recording unit 41 is configured to record, in the shared memory, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed after a predetermined operation is performed in the process of processing the first transaction, To enter the waiting process relative to the first transaction;

The determining unit 42 is configured to determine whether there is a pending task waiting for the end of the process among the multiple pending tasks that have been recorded in the shared memory, and the multiple pending tasks are recorded by the predetermined number of executives. ;as well as

The continuing execution unit 43 is configured to continue to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task in a case where it is determined that the waiting process corresponding to the second to-be-processed task is over, wherein The multiple to-be-processed tasks include the second to-be-processed task.

In one embodiment, the device further includes a transaction execution unit 44 configured to obtain from the first buffer in the shared memory when it is determined that the respective waiting processes of the multiple pending tasks have not ended. The second transaction to be processed, and the execution of the second transaction is started.

In an embodiment, the shared memory includes a second buffer area, wherein the recording unit 41 is further configured to, after processing the first transaction, in a case where it is determined that the second transaction has not been submitted, in the The first to-be-processed task corresponding to the first transaction is recorded in the second buffer zone, wherein the second transaction is the previous transaction of the first transaction according to a predetermined submission sequence.

In one embodiment, the determining unit 42 is further configured to determine whether the waiting process of the task to be processed corresponding to the smallest transaction number in the second buffer is over based on the transaction currently to be submitted recorded in the shared memory, To determine whether there is a task to be processed waiting for the end of the process in the second buffer zone, wherein the transaction number corresponds to the submission sequence of the transaction.

In one embodiment, the continued execution unit 43 is further configured to, in a case where it is determined that the waiting process of the second to-be-processed task in the second buffer is over, based on the corresponding to the second to-be-processed task Execution information, continue to execute the submission of the third transaction, wherein the second pending task corresponds to the third transaction.

In an embodiment, the shared memory includes a third buffer area, and the first transaction includes a read operation of the first variable, wherein the recording unit 41 is further configured to: upon request, the first variable is read. After a variable is read, the first to-be-processed task corresponding to the first transaction is recorded in the third buffer, wherein the first to-be-processed task includes a record of the first variable.

In one embodiment, the third buffer includes the second to-be-processed task, and the second to-be-processed task corresponds to the reading operation of the second variable in the second transaction, and the determining unit 42 It is also 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, it is determined that the waiting process of the second to-be-processed task ends.

In an embodiment, the determining unit 42 is further configured to, for the multiple pending tasks that have been recorded in the third buffer, determine each of the pending tasks in the descending order based on the transaction number corresponding to each pending task. Whether the waiting process of the task to be processed is completed, wherein the second task to be processed is the first determined task to be processed after the waiting process has ended, and the transaction number corresponds to the predetermined submission sequence of the transaction.

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 in the shared memory, wherein the The predetermined address corresponds to the second transaction.

In one embodiment, the continued execution unit 43 is further configured to, in a case where it is determined that there is a second to-be-processed task waiting for the end of the process in the third buffer, based on the data corresponding to the second to-be-processed task The execution information and the variable value of the second variable continue to execute the second transaction.

In one embodiment, the shared memory includes a fourth buffer, and the first transaction includes a read operation of the first variable, wherein the recording unit 41 is further configured to: After fetching the code of the operation, it is determined whether each transaction whose submission sequence is before the first transaction and is not submitted is a conflict transaction in which the write operation to the first variable has been performed, and each transaction includes the second transaction. In the case where the second transaction is the conflicting transaction closest to the first transaction, the first pending task corresponding to the first transaction is recorded in the fourth buffer, wherein the first pending task includes the second The record of the transaction.

In an embodiment, the determining unit 42 is further configured to determine whether there is a waiting process to be completed among the multiple pending tasks recorded in the fourth buffer based on the currently submitted transaction recorded in the shared memory. Pending tasks.

In one embodiment, the shared memory includes a fifth buffer, and the first transaction includes a read operation of the first variable, wherein the recording unit 41 is further configured to: After fetching the code of the operation, it is inferred whether each transaction whose submission order is before the first transaction and is not submitted is a conflict transaction that will write the first variable. Each transaction includes the second transaction. In the case where the second transaction is the closest conflict transaction to the first transaction, the first pending task corresponding to the first transaction is recorded in the fifth buffer, wherein the first pending task includes The record of the transaction.

In an embodiment, the shared memory includes at least one buffer, and the at least one buffer corresponds to at least one task to be processed, wherein the determining unit 42 is further configured to, based on the at least one buffer The predetermined sequence of zones determines whether there are pending tasks waiting for the end of the process in each buffer.

It should be understood that the descriptions of "first", "second", etc. in this article are merely to distinguish similar concepts for the sake of simplicity of description, and do not have other limiting effects.

The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Those of ordinary skill in the art should be further aware that the units and algorithm steps of the examples described in the embodiments disclosed herein can be implemented by electronic hardware, computer software or a combination of the two, in order to clearly illustrate the hardware For the interchangeability with software, the composition and steps of each example have been described generally in terms of function in the above description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. A person of ordinary skill in the art may use different methods for each specific application to implement the described functions, but such implementation should not be considered beyond the scope of the present application.

The steps of the method or algorithm described in combination with the embodiments disclosed in this document can be implemented by hardware, a software module executed by a processor, or a combination of the two. The software module can be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or all areas in the technical field. Any other known storage media.

The specific embodiments described above further describe the purpose, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific embodiments of the present invention, and are not intended to limit the scope of the present invention. The protection scope, any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

A method for concurrently executing transactions in a blockchain. The method is executed at a first node in the blockchain. The first node currently executes transactions concurrently through a preset predetermined number of executive entities. The predetermined The number of executive bodies includes a first executive body, which is currently processing a first transaction, and the method is executed by the first executive body, including:

After a predetermined operation is performed in the process of processing the first transaction, the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task are recorded in the shared memory so as to be relative to the first to-be-processed task. The transaction enters the waiting process;

For the multiple pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process, and the multiple pending tasks are recorded by the predetermined number of executives; and

In the case where it is determined that the waiting process corresponding to the second to-be-processed task ends, the second to-be-processed task is continued to be executed based on the execution information corresponding to the second to-be-processed task, wherein the multiple to-be-processed tasks include The second task to be processed.
The method according to claim 1, further comprising, in the case where it is determined that the respective waiting processes of the plurality of to-be-processed tasks are not finished, obtaining the second transaction to be processed from the first buffer in the shared memory, and Start the execution of the second transaction.
The method according to claim 1, wherein the shared memory includes a second buffer, wherein after a predetermined operation is performed in the process of processing the first transaction, the first transaction corresponding to the first transaction is recorded in the shared memory. The to-be-processed task and the execution information corresponding to the first to-be-processed task include, after processing the first transaction, in the case where it is determined that the second transaction has not been submitted, recording the first transaction in the second buffer The corresponding first task to be processed, wherein the second transaction is the previous transaction of the first transaction according to a predetermined submission order.
The method according to claim 3, wherein, for the plurality of pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process includes, based on the current transactions recorded in the shared memory that should be submitted , Determine whether the waiting process of the task to be processed corresponding to the smallest transaction number in the second buffer is over, to determine whether there is a task to be processed in the second buffer that has the end of the waiting process, wherein the transaction number corresponds to The order of submission of the transaction.
The method according to claim 4, wherein, in a case where it is determined that the waiting process corresponding to the second to-be-processed task ends, continuing to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task comprises , In the case of determining that the waiting process of the second to-be-processed task in the second buffer is over, continue to perform the submission of the third transaction based on the execution information corresponding to the second to-be-processed task, wherein the The second pending task corresponds to the third transaction.
The method according to claim 1, wherein the shared memory includes a third buffer, the first transaction includes a read operation of a first variable, and wherein the predetermined is performed in the process of processing the first transaction After the operation, recording the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task in the shared memory includes, after requesting the reading of the first variable, in the The first to-be-processed task corresponding to the first transaction is recorded in the third buffer, wherein the first to-be-processed task includes a record of the first variable.
The method according to claim 6, wherein the third buffer includes the second to-be-processed task, and the second to-be-processed task corresponds to a reading operation of a second variable in a second transaction, For the multiple pending tasks that have been recorded in the shared memory, determining whether there are any pending tasks waiting for the end of the process includes determining whether the variable value of the second variable is returned, and determining whether the variable of the second variable is returned. In the case where the value is returned, it is determined that the waiting process of the second to-be-processed task ends.
The method according to claim 7, wherein, for the multiple pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process includes: Multiple pending tasks, based on the descending order of the transaction number corresponding to each pending task, determine in turn whether the waiting process of each pending task is over, wherein, the second pending task is the end of the waiting process determined for the first time The task to be processed, wherein the transaction number corresponds to a predetermined submission sequence of the transaction.
The method according to claim 7, wherein determining whether the variable value of the second variable is returned comprises, based on whether the variable value of the second variable is stored in a predetermined address in the shared memory, determining the value of the second variable Whether the variable value is returned, wherein the predetermined address corresponds to the second transaction.
8. The method according to claim 7, wherein, in a case where it is determined that the waiting process corresponding to the second to-be-processed task is finished, continuing to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task comprises In the case where it is determined that there is a second to-be-processed task waiting for the end of the process in the third buffer, continue to execute all based on the execution information corresponding to the second to-be-processed task and the variable value of the second variable The second transaction.
The method according to claim 1, wherein the shared memory includes a fourth buffer, the first transaction includes a read operation of the first variable, and wherein the predetermined is performed in the process of processing the first transaction After the operation, recording in the shared memory the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task includes, after the code for the read operation is executed, determining that the order of submission is Whether each transaction that has not been submitted before the first transaction is a conflict transaction in which the write operation to the first variable has been performed, the each transaction includes a second transaction, and the second transaction is determined to be the closest to the first transaction In the case of conflicting transactions, the first to-be-processed task corresponding to the first transaction is recorded in the fourth buffer zone, wherein the first to-be-processed task includes a record of the second transaction.
The method according to claim 11, wherein, for the multiple pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process includes, based on the current transactions recorded in the shared memory that should be submitted , Determining whether there is a pending task waiting for the end of the process among the multiple pending tasks recorded in the fourth buffer.
The method according to claim 1, wherein the shared memory includes a fifth buffer, the first transaction includes a read operation of a first variable, and wherein the predetermined is performed in the process of processing the first transaction After the operation, recording the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task in the shared memory includes, after executing the code of the read operation, inferring the submission sequence is Whether each transaction that has not been submitted before the first transaction is a conflict transaction that is about to write the first variable, the each transaction includes a second transaction, and it is inferred that the second transaction is the closest conflict to the first transaction In the case of a transaction, the first task to be processed corresponding to the first transaction is recorded in the fifth buffer zone, wherein the first task to be processed includes a record of the second transaction.
The method according to claim 1, wherein the shared memory includes at least one buffer, and the at least one buffer corresponds to at least one task to be processed, wherein the number of records in the shared memory is 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 in each buffer based on a predetermined sequence of the at least one buffer.
A device for concurrently executing transactions in a blockchain. The device is deployed in a first executor in a first node in the blockchain. The first node currently passes a preset predetermined number of executors. The concurrent execution transaction includes a first executive body, and the first executive body is currently processing the first transaction, and the device includes:

The recording unit is configured to record, in the shared memory, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed after a predetermined operation is performed in the process of processing the first transaction, to Enter the waiting process with respect to the first transaction;

The determining unit is configured to determine whether there is a pending task waiting for the end of the process among the multiple pending tasks that have been recorded in the shared memory, and the multiple pending tasks are recorded by the predetermined number of executives; as well as

The continuing execution unit is configured to continue to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task in a case where it is determined that the waiting process corresponding to the second to-be-processed task is over, wherein the The multiple to-be-processed tasks include the second to-be-processed task.
The device according to claim 15, further comprising a transaction execution unit configured to, in a case where it is determined that the waiting processes of the multiple pending tasks are not finished, obtain the pending tasks from the first buffer in the shared memory. Process the second transaction, and start execution of the second transaction.
The device according to claim 15, wherein the shared memory includes a second buffer area, and wherein the recording unit is further configured to, after processing the first transaction, in a case where it is determined that the second transaction has not been submitted , Record the first pending task corresponding to the first transaction in the second buffer zone, wherein the second transaction is the previous transaction of the first transaction according to a predetermined submission order.
The device according to claim 17, wherein the determining unit is further configured to determine the waiting task of the task to be processed corresponding to the smallest transaction number in the second buffer based on the transaction that should be submitted currently recorded in the shared memory Whether the process is over to determine whether there is a pending task waiting for the process to end in the second buffer zone, wherein the transaction number corresponds to the order of submission of the transaction.
The apparatus according to claim 18, wherein the continuing execution unit is further configured to, in a case where it is determined that the waiting process of the second pending task in the second buffer is over, based on the comparison with the second pending task The execution information corresponding to the processing task continues to execute the submission of the third transaction, wherein the second pending task corresponds to the third transaction.
The device according to claim 15, wherein the shared memory includes a third buffer, and the first transaction includes a read operation of a first variable, wherein the recording unit is further configured to: After the first variable is read, the first task to be processed corresponding to the first transaction is recorded in the third buffer area, wherein the first task to be processed includes information about the first variable recording.
22. The device of claim 20, wherein the third buffer includes the second to-be-processed task, and the second to-be-processed task corresponds to a read operation of a second variable in a second transaction, The determining unit is further configured to determine whether the variable value of the second variable is returned, and in a case where the variable value of the second variable is determined to be returned, determine that the waiting process of the second to-be-processed task ends.
22. The device according to claim 21, wherein the determining unit is further configured to, for the multiple pending tasks that have been recorded in the third buffer, based on the descending order of the transaction number corresponding to each pending task , Determine in turn whether the waiting process of each task to be processed is over, wherein the second task to be processed is the first determined task to be processed after the waiting process ends, and the transaction number corresponds to the predetermined submission sequence of the transaction.
22. The apparatus according to claim 21, 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 in the shared memory, Wherein, the predetermined address corresponds to the second transaction.
21. The apparatus according to claim 21, wherein the continuing execution unit is further configured to, in a case where it is determined that there is a second pending task waiting for the end of the process in the third buffer area, based on the comparison with the second pending task. The execution information corresponding to the processing task and the variable value of the second variable are processed, and the second transaction is continued to be executed.
The device according to claim 15, wherein the shared memory includes a fourth buffer, and the first transaction includes a read operation of a first variable, wherein the recording unit is further configured to execute After the code of the read operation, it is determined whether each transaction whose submission sequence is before the first transaction and is not submitted is a conflict transaction in which the write operation to the first variable has been performed, and the each transaction includes the second transaction , In the case of determining that the second transaction is the closest conflict transaction to the first transaction, the first pending task corresponding to the first transaction is recorded in the fourth buffer, wherein the first pending task is Including the record of the second transaction.
The device according to claim 25, wherein the determining unit is further configured to determine whether there are multiple pending tasks recorded in the fourth buffer based on the currently submitted transaction recorded in the shared memory Pending tasks waiting for the end of the process.
The device according to claim 15, wherein the shared memory includes a fifth buffer, and the first transaction includes a read operation of a first variable, wherein the recording unit is further configured to execute After the code of the read operation, it is inferred whether each transaction whose submission sequence is before the first transaction and is not submitted is a conflict transaction that will write the first variable, and each transaction includes the second transaction. In the case where it is inferred that the second transaction is the closest conflict transaction to the first transaction, the first pending task corresponding to the first transaction is recorded in the fifth buffer, wherein the first pending task is Including the record of the second transaction.
The device according to claim 15, wherein the shared memory includes at least one buffer, and the at least one buffer corresponds to at least one task to be processed, wherein the determining unit is further configured to Describe the predetermined sequence of the at least one buffer zone, and determine whether there are pending tasks in each buffer zone waiting for the process to end.
A computer-readable storage medium having a computer program stored thereon, and when the computer program is executed in a computer, the computer is caused to execute the method according to any one of claims 1-14.
A computing device, comprising a memory and a processor, characterized in that executable code is stored in the memory, and when the processor executes the executable code, the method described in any one of claims 1-14 is implemented. method.