Method and device for concurrently executing transactions in a blockchain

Abstract

The embodiments of the present specification provide a method and device for concurrently executing transactions in a blockchain, wherein the method is executed by a first execution body in a first node in the blockchain, and includes: after performing a predetermined operation in the process of processing a first transaction, recording a first to-be-processed task corresponding to the first transaction and execution information corresponding to the first to-be-processed task in a shared memory, so as to enter a waiting process relative to the first transaction; for a plurality of to-be-processed tasks already recorded in the shared memory, determining whether there is a to-be-processed task whose waiting process ends, wherein the plurality of to-be-processed tasks are recorded by the predetermined number of execution bodies; and in the case of determining that the waiting process corresponding to a 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, wherein the plurality of to-be-processed tasks include the second to-be-processed task.

Description

[0001] This application is a divisional application of the invention patent application with application number 201910816530.6 filed on August 30, 2019, and entitled “Method and device for concurrently executing transactions in blockchain”. Technical Field

[0002] 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 Art

[0003] Blockchain technology is a new distributed infrastructure and computing paradigm built on a peer-to-peer (P2P) network, using chain data structures to verify and store data, using distributed node consensus algorithms to generate and update data, using cryptography to ensure the security of data transmission and access, and using smart contracts composed of automated script codes to program and operate data. Blockchain technology, also known as distributed ledger technology, is a decentralized distributed database technology characterized by decentralization, openness, transparency, immutability, and trustworthiness. Every piece of data in the blockchain will be broadcast to blockchain nodes across the entire network, and each full node has full and consistent data. Nodes in the blockchain perform services such as transfers and data storage by sending transactions. The accounting nodes in the blockchain collect transactions in the blockchain in the transaction pool, execute the transactions, and after executing the transactions, package the transactions into blocks and spread them to the blockchain. The verification nodes in the blockchain will verify the blocks sent from the accounting nodes. After the verification is passed, each node will execute each transaction included in the block when receiving the block. In order to ensure the data consistency of each node, when executing multiple transactions in a block in each node, the submission order of the multiple transactions needs to be consistent, so that a consistent execution result can be obtained. Therefore, in the prior art, the accounting node will number the multiple transactions to be executed according to a predetermined rule before executing the transaction, and execute the multiple transactions in sequence according to the order of the numbers, that is, submit the multiple transactions in sequence, and other nodes will also execute and submit the multiple transactions in sequence according to the above transaction number order after receiving the block. However, the multiple transactions are not necessarily interdependent. In the case where there is no dependency between the two transactions, the concurrent execution of the two transactions does not affect the final result. If there is a dependency between the two concurrently executed transactions, the concurrent execution will affect the final result.

[0004] Therefore, a more efficient method of executing multiple transactions concurrently in a blockchain is needed. Summary of the invention

[0005] The embodiments of this specification are intended to provide a more efficient solution for concurrently executing transactions to address the deficiencies in the prior art.

[0006] To achieve the above-mentioned purpose, in one aspect, this specification provides a method for concurrently executing transactions in a blockchain, wherein the method is executed at a first node in the blockchain, wherein transactions are currently concurrently executed by a preset number of execution bodies in the first node, including a first execution body, wherein the first execution body is currently processing a first transaction, and wherein the method is executed by the first execution body, and comprises:

[0007] After performing a predetermined operation in the process of processing the first transaction, recording a first to-be-processed task corresponding to the first transaction and execution information corresponding to the first to-be-processed task in a shared memory, so as to enter a waiting process with respect to the first transaction;

[0008] For a plurality of pending tasks recorded in the shared memory, determining whether there is a pending task waiting for the process to end, wherein the plurality of pending tasks are recorded by the predetermined number of execution bodies; and

[0009] In the case where it is determined that the waiting process corresponding to the second task to be processed is completed, the second task to be processed is continued to be executed based on the execution information corresponding to the second task to be processed, wherein the plurality of tasks to be processed include the second task to be processed.

[0010] In one embodiment, the method further includes, when it is determined that the waiting processes of the plurality of tasks to be processed have not ended, obtaining a second transaction to be processed from a first buffer in a shared memory, and starting to execute the second transaction.

[0011] In one embodiment, the shared memory includes a second buffer, wherein after a predetermined operation is performed during processing of a first transaction, a first to-be-processed task corresponding to the first transaction and execution information corresponding to the first to-be-processed task are recorded in the shared memory, including: after processing the first transaction, in the case where it is determined that the second transaction is not submitted, the first to-be-processed task corresponding to the first transaction is recorded in the second buffer, wherein the second transaction is a previous transaction of the first transaction according to a predetermined submission order.

[0012] In one embodiment, for multiple pending tasks recorded in the shared memory, determining whether there is a pending task waiting for the end of the process includes, based on the transaction currently to be submitted recorded in the shared memory, determining whether the waiting process of the pending task corresponding to the smallest transaction number in the second buffer is ended, so as to determine whether there is a pending task waiting for the end of the process in the second buffer, wherein the transaction number corresponds to the submission order of the transactions.

[0013] In one embodiment, when it is determined that the waiting process corresponding to the second pending task has ended, continuing to execute the second pending task based on the execution information corresponding to the second pending task includes, when it is determined that the waiting process of the second pending task in the second buffer has ended, continuing to submit a third transaction based on the execution information corresponding to the second pending task, wherein the second pending task corresponds to the third transaction.

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

[0015] In one embodiment, the third buffer includes the second pending task, and the second pending task corresponds to the read operation of the second variable in the second transaction. For the multiple pending tasks recorded in the shared memory, determining whether there is a pending task waiting for the end of the process includes determining whether the variable value of the second variable is returned. When it is determined that the variable value of the second variable is returned, it is determined that the waiting process of the second pending task is ended.

[0016] In one embodiment, for multiple pending tasks recorded in the shared memory, determining whether there is a pending task whose waiting process is over includes, for multiple pending tasks recorded in the third buffer, determining in sequence from small to large the transaction numbers corresponding to the respective pending tasks, whether the waiting process of each pending task is over, wherein the second pending task is the pending task whose waiting process is determined to be over for the first time, and wherein the transaction numbers correspond to the predetermined submission order of the transactions.

[0017] 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.

[0018] In one embodiment, when it is determined that the waiting process corresponding to the second pending task has ended, continuing to execute the second pending task based on the execution information corresponding to the second pending task includes: when it is determined that there is a second pending task whose waiting process has ended in the third buffer, continuing to execute the second transaction based on the execution information corresponding to the second pending task and the variable value of the second variable.

[0019] In one embodiment, the shared memory includes a fourth buffer, the first transaction includes a read operation on the first variable, wherein after a predetermined operation is performed in the process of processing the first transaction, a first to-be-processed task corresponding to the first transaction is recorded in the shared memory, and execution information corresponding to the first to-be-processed task includes: after executing the code for the read operation, determining whether each transaction that is submitted before the first transaction in a submission order and has not been submitted is a conflicting transaction that has executed a write operation on the first variable, wherein each transaction includes a second transaction, and when it is determined that the second transaction is the conflicting transaction closest to the first transaction, the first to-be-processed task corresponding to the first transaction is recorded in the fourth buffer, wherein the first to-be-processed task includes a record of the second transaction.

[0020] In one embodiment, for multiple pending tasks recorded in the shared memory, determining whether there is a pending task waiting for the process to end includes, based on the current transaction to be submitted recorded in the shared memory, determining whether there is a pending task waiting for the process to end among the multiple pending tasks recorded in the fourth buffer.

[0021] In one embodiment, the shared memory includes a fifth buffer, the first transaction includes a read operation on the first variable, wherein after a predetermined operation is performed in the process of processing the first transaction, a first to-be-processed task corresponding to the first transaction is recorded in the shared memory, and execution information corresponding to the first to-be-processed task includes: after executing the code for the read operation, it is inferred whether each transaction that is submitted before the first transaction and has not been submitted is a conflicting transaction that will perform a write operation on the first variable, the transactions include a second transaction, and in the case where it is inferred that the second transaction is the conflicting transaction closest to the first transaction, the first to-be-processed task corresponding to the first transaction is recorded in the fifth buffer, wherein the first to-be-processed task includes a record of the second transaction.

[0022] In one embodiment, the shared memory includes at least one buffer, and the at least one buffer corresponds to at least one pending task respectively. Among them, for multiple pending tasks recorded in the shared memory, determining whether there is a pending task waiting for the process to end includes, based on a predetermined order of the at least one buffer, determining whether there is a pending task waiting for the process to end in each buffer.

[0023] Another aspect of the present specification provides a device for concurrently executing transactions in a blockchain, wherein the device is deployed in a first execution body in a first node in the blockchain, wherein transactions are currently concurrently executed by a predetermined number of execution bodies in the first node, including the first execution body, and the first execution body is currently processing the first transaction, wherein the device comprises:

[0024] a recording unit configured to, after performing a predetermined operation in the process of processing the first transaction, 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, so as to enter a waiting process with respect to the first transaction;

[0025] a determining unit configured to determine, for a plurality of pending tasks recorded in the shared memory, whether there is a pending task waiting for the end of a process, wherein the plurality of pending tasks are recorded by the predetermined number of execution bodies; and

[0026] The continuing execution unit is configured to, when it is determined that the waiting process corresponding to the second task to be processed is ended, continue to execute the second task to be processed based on the execution information corresponding to the second task to be processed, wherein the second task to be processed is included in the multiple tasks to be processed.

[0027] In one embodiment, the device further includes a transaction execution unit configured to, when it is determined that the waiting processes of the plurality of tasks to be processed have not ended, obtain a second transaction to be processed from a first buffer in a shared memory and start executing the second transaction.

[0028] In one embodiment, the shared memory includes a second buffer, wherein the recording unit is further configured to, after processing the first transaction, record a first to-be-processed task corresponding to the first transaction in the second buffer in the case where it is determined that the second transaction is not submitted, wherein the second transaction is a previous transaction of the first transaction according to a predetermined submission order.

[0029] In one embodiment, the determination unit is further configured to determine whether the waiting process of the pending task corresponding to the smallest transaction number in the second buffer has ended based on the transaction currently to be submitted recorded in the shared memory, so as to determine whether there is a pending task in the second buffer whose waiting process has ended, wherein the transaction number corresponds to the submission order of the transaction.

[0030] In one embodiment, the continuing execution unit is further configured to, in the event that it is determined that the waiting process of the second pending task in the second buffer is ended, continue to execute the submission of the third transaction based on the execution information corresponding to the second pending task, wherein the second pending task corresponds to the third transaction.

[0031] In one embodiment, the shared memory includes a third buffer, and the first transaction includes a read operation on a first variable, wherein the recording unit is further configured to, after requesting to read the first variable, record a first to-be-processed task corresponding to the first transaction in the third buffer, wherein the first to-be-processed task includes a record of the first variable.

[0032] In one embodiment, the third buffer includes the second pending task, and the second pending task corresponds to a read operation on a second variable in a second transaction. The determination unit is further configured to determine whether the 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, determine that the waiting process of the second pending task is ended.

[0033] In one embodiment, the determination unit is further configured to determine, for multiple pending tasks recorded in the third buffer, whether the waiting process of each pending task is ended in sequence based on the transaction numbers corresponding to each pending task in ascending order, wherein the second pending task is the pending task whose waiting process is determined to have ended for the first time, and wherein the transaction number corresponds to a predetermined submission order of transactions.

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

[0035] In one embodiment, the continuing execution unit is also configured to, in the event that it is determined that there is a second pending task waiting for the process to end in the third buffer, continue to execute the second transaction based on the execution information corresponding to the second pending task and the variable value of the second variable.

[0036] In one embodiment, the shared memory includes a fourth buffer, wherein the recording unit is further configured to, after executing the code for the read operation, determine whether each transaction whose submission order is before the first transaction and which has not been submitted is a conflicting transaction that has executed a write operation on the first variable, wherein the transactions include the second transaction, and in the case where it is determined that the second transaction is the conflicting transaction closest to the first transaction, record a first to-be-processed task corresponding to the first transaction in the fourth buffer, wherein the first to-be-processed task includes a record of the second transaction.

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

[0038] In one embodiment, the shared memory includes a fifth buffer, and the first transaction includes a read operation on the first variable, wherein the recording unit is further configured to, after executing the code for the read operation, infer whether each transaction whose submission order is before the first transaction and which has not been submitted is a conflicting transaction that will perform a write operation on the first variable, wherein the transactions include a second transaction, and in the case where it is inferred that the second transaction is the conflicting transaction closest to the first transaction, record a first to-be-processed task corresponding to the first transaction in the fifth buffer, wherein the first to-be-processed task includes a record of the second transaction.

[0039] 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, wherein the determination unit is further configured to determine whether there are tasks to be processed in each buffer waiting for the process to end based on a predetermined order of the at least one buffer.

[0040] On the other hand, the present specification provides 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 perform any of the above methods.

[0041] On the other hand, the present specification provides a computing device, including a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, any of the above methods is implemented.

[0042] By implementing a solution for concurrently executing transactions according to the embodiments of the present specification, when the executor needs to wait during the process of executing a transaction, the processing information of the transaction is recorded, and other pending tasks or other pending transactions are obtained from the shared memory for processing, thereby reducing the waiting time of the executor and speeding up the overall speed of concurrent execution of transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The embodiments of this specification are described in conjunction with the accompanying drawings to make the embodiments of this specification clearer:

[0044] Figure 1 A schematic diagram of a blockchain system according to an embodiment of this specification is shown;

[0045] Figure 2 A schematic diagram showing that each node in a blockchain executes transactions concurrently through multiple threads;

[0046] Figure 3 A flow chart of a method for concurrently executing transactions in a blockchain according to one embodiment of the present specification is shown;

[0047] Figure 4 A device 400 for concurrently executing transactions in a blockchain according to one embodiment of the present specification is shown. DETAILED DESCRIPTION

[0048] The embodiments of this specification will be described below with reference to the accompanying drawings.

[0049] Figure 1 A schematic diagram of a blockchain system according to an embodiment of this specification is shown. Figure 1 As shown, the system includes multiple nodes constituting a blockchain (six nodes are schematically shown in the figure), and these 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 put them into a transaction pool and compete for the right to keep accounts. For example, node 11 in the figure becomes a bookkeeping node by acquiring the right to keep accounts. After becoming a bookkeeping node, node 11 will execute multiple transactions in its transaction pool, and package the multiple transactions into blocks and send them to other nodes, such as node 12. Node 12 will verify the block and similarly execute multiple transactions in the block. After a predetermined number of nodes verify the block, that is, a consensus is reached on the block, other nodes in the blockchain (such as node 13) will not need to continue to verify the block, but directly execute the transactions in the block to update local related data.

[0050] Figure 2 A schematic diagram showing that each node in the blockchain executes transactions concurrently through multiple threads. It can be understood that the threads can also be replaced by processes, coroutines and other execution bodies. Figure 2 As shown in , 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 in the node is 4, the number of preset threads in the thread pool is 6, so that the 6 threads compete for the CPU, and only after the CPU is preempted can they start executing the tasks in the task pool.

[0051] In the process of multiple threads executing multiple transactions concurrently, the multiple transactions may involve calculations of multiple variables. In the case where the same variables are not involved in two transactions, the execution order will not affect the final calculation result, but in the case where the same variables are involved in two transactions, the execution order will affect the final calculation result. In the embodiment of this specification, in order to ensure that the execution results of multiple transactions by each node are the same, while executing multiple transactions concurrently, the conflict of access to variables between transactions is considered, so that some threads in the parallel execution threads need to go through a waiting process. Or waiting is required when waiting to return access to storage.

[0052] like Figure 2 As shown in , the figure includes a shared memory of the first node, and the shared memory includes, for example, a buffer 1 for indicating pending transactions, and the shared memory is readable and writable relative to all threads. For example, the first buffer currently records 10 pending transactions 1, 2, ..., 10, wherein the bit boxes corresponding to the numbers 1, 2, ..., 10 in the figure should initially be 1, indicating that they are all pending transactions, wherein the numbers of transactions 1 to 10 correspond to the submission order of each transaction. After starting to execute transactions concurrently, for example, threads 1 to 4 respectively seize CPUs 1 to 4, so that threads 1 to 4 can respectively obtain a task from the first buffer for processing, for example, threads 1 to 4 respectively start to process transactions 1 to 4, and after starting to process transactions 1 to 4, threads 1 to 4 respectively modify the bits corresponding to transactions 1 to 4 in the first buffer to 0 to indicate that these transactions have begun to execute. It can be understood that although the figure schematically shows that thread 1 preempts CPU 1 and executes transaction 1, thread 2 preempts CPU 2 and executes transaction 2, etc., it can be understood that the content shown in the figure is only for illustrative purposes, and the thread numbers, CPU numbers and transaction numbers do not correspond to each other. For example, thread 1 may preempt CPU 2 and execute transaction 3, etc.

[0053] Figure 2Also shown are multiple buffers for recording pending tasks, buffers 2 to 5, wherein each buffer corresponds to a waiting process. For example, buffer 2 corresponds to the waiting process of waiting for submission after executing a transaction, buffer 3 corresponds to the waiting process of requesting to read to wait for the return of a variable value, buffer 4 corresponds to the waiting process of waiting for the submission of the previous transaction based on the variable writing record before reading, and buffer 5 corresponds to the waiting process of waiting for the submission or writing of the previous transaction based on the probability of transaction conflict before reading. In the embodiment of this specification, in order to execute transactions concurrently, the process of executing transactions includes the process of processing transactions and the process of submitting transactions, wherein the process of processing transactions is to store the result of processing transactions in the buffer corresponding to the transaction, and the process of submitting transactions is to store the final processing result in the shared memory shared by each transaction. For example, after thread 3 processes 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 sequence according to its numbering order, so transaction 3 needs to wait for the previous transaction 2 to be submitted before submitting. In this case, thread 3 records the position corresponding to transaction 3 in buffer 2, for example, changes the initial 0 to 1, and then thread 3 goes to the buffer to get a new task. For example, thread 3 may first check whether there is a task in buffer 2 waiting for the process to end. Figure 2 The current transaction window is also recorded in the shared memory in the transaction window, and the current transaction window can be maintained by the thread that has submitted the transaction. For example, after submitting transaction 1, thread 1 can modify the first transaction in the transaction window to 2. Thus, the transaction window moves one position backward in 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 checking buffer 2, thread 3 can first determine whether transaction 2 is the transaction to be submitted based on the window. In the case that there is no task waiting for the process to end in buffer 2, it can be checked whether there is a task waiting for the process to end in buffer 3, and so on. In the case that there is no task waiting for the process to end in buffers 2 to 5, the transaction to be processed, such as transaction 6, can be obtained from buffer 1. When thread 3 also encounters a waiting process in the process of executing transaction 6, it will also record the corresponding task to be processed 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 task to be processed corresponding to transaction 6 in buffer 4. Then, similarly, thread 3 first determines in buffers 2 to 5 whether there are any pending tasks waiting for the process to end.

[0054] Understandably, the above Figure 2The description is only for illustration and is not intended to limit the scope of the embodiments of this 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 the corresponding information. The process of concurrently executing transactions according to the embodiments of this specification will be described in detail below.

[0055] Figure 3 A flow chart of a method for concurrently executing transactions in a blockchain according to an embodiment of the present specification is shown. The method is executed at a first node in the blockchain. A first execution body is preset in the first node. The first execution body is currently processing a first transaction. The method is executed by the first execution body and includes:

[0056] Step S302, after performing a predetermined operation in the process of processing the first transaction, recording a first to-be-processed task corresponding to the first transaction and execution information corresponding to the first to-be-processed task in a shared memory, so as to enter a waiting process with respect to the first transaction;

[0057] Step S304, for the multiple pending tasks recorded in the shared memory, determining whether there is a pending task waiting for the process to end; and

[0058] Step S306, when it is determined that the waiting process corresponding to the second task to be processed is finished, continue to execute the second task to be processed based on the execution information corresponding to the second task to be processed, wherein the plurality of tasks to be processed include the second task to be processed.

[0059] First, in step S302, after performing a predetermined operation in the process of processing the first transaction, a first to-be-processed task corresponding to the first transaction and execution information corresponding to the first to-be-processed task are recorded in a shared memory to enter a waiting process relative to the first transaction.

[0060] As mentioned above Figure 2 The first execution body may be, for example, a thread, a process, a coroutine or other execution body, and the shared memory is shared with respect to multiple execution bodies for concurrently executing transactions. Threads will be used as an example for explanation below.

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

[0062] In one embodiment, as described above with reference to Figure 2 As described in, the multiple concurrently executed transactions have preset a predetermined submission order, for example Figure 2The transactions 1 to 10 in the must be submitted in order of their numbers from small to large to ensure that the execution results of the multiple transactions on each node are the same. Here, in the node, when the thread executes the transaction, it first saves the processing result to the buffer corresponding only to the transaction, and only saves the execution result to the shared memory shared by all transactions after submission. For example, in the process of processing the first transaction, it is necessary to write to the first variable, then the value of the first variable after the write operation is first saved in the buffer corresponding only to the first transaction, and the value can only be used when processing the first transaction, and the value will not be read or written when processing other transactions. After submitting the first transaction, 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.

[0063] Since each transaction has a predetermined submission order, Figure 2 As shown in, for example, the first transaction is Figure 2 Transaction 6 in the figure, the first execution body is thread 3 in the figure. If the transaction before transaction 6 has not been submitted after thread 3 has processed transaction 6, thread 3 needs to wait for transaction 5 to be submitted before submitting transaction 6. Here, thread 3 can determine whether transaction 5 is submitted based on the transaction window parameters preset in the shared memory. The maximum total number of transactions that can be executed concurrently is controlled by the transaction window. The two sides of the transaction window are the transaction with the smallest number and the transaction with the largest number currently executed concurrently, for example Figure 2 The 1 and 6 in indicate that the transactions currently being executed concurrently are transactions 1 to 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 Figure 2 As shown in , the bit corresponding to transaction 6 in buffer 2 is modified to 1 to add a pending task corresponding to transaction 6. The pending task can be executed only after transaction 5 is submitted. At the same time, the execution information corresponding to the pending task, 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.

[0064] In one embodiment, transaction 6 includes a read operation on variable k1. After thread 3 starts executing the code for the read operation, it sends a read request for variable k1 to the hardware or thread for reading variables. Figure 2 In the byte corresponding to transaction 6 in buffer 3 shown in FIG. 1 , “k1” is recorded to add a pending task corresponding to transaction 6, and the pending task continues to execute after the value of variable k1 is returned.

[0065] In one embodiment, transaction 6 includes a read operation on variable k1. After thread 3 starts executing the code for the read operation, it queries the write buffer in the shared memory. The write buffer records the write status of various variables (including variable k1) in the current processing of each transaction. For example, the write buffer only records the write to variable k1 by transaction 4, and does not record the write to variable k1 by transaction 5. Since, based on this record, transaction 4 will change the value of k1 in the variable table in the shared memory after submission, transaction 6 needs to wait for transaction 4 to be submitted before reading the value of variable k1, otherwise the wrong value of k1 will be read. After checking the write buffer, thread 3 Figure 2 "4" is recorded in the byte corresponding to transaction 6 in buffer 3 in order to add a pending task corresponding to transaction 6. The "4" corresponds to transaction 4, indicating that the pending task can continue to be executed after transaction 4 is submitted.

[0066] In one embodiment, transaction 6 includes a read operation on variable k1. After thread 3 starts executing the code for the read operation, it infers the transactions (e.g. Figure 2 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 all write to variable k1. Therefore, it is necessary to wait until transaction 5 is submitted before performing the read operation in transaction 6. If transaction 5 writes the write value of k1 to the buffer corresponding to transaction 5 in the shared memory (the buffer is not the variable table corresponding to each transaction) during the processing, it is possible to wait until transaction 5 completes the write to k1 before performing the read of k1. In one method, thread 3 can determine the conflict probability of transaction 6 with 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 to k1, thereby determining 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 the predetermined threshold, and the write probability of transaction 5 to k1 is less than the predetermined threshold, thread 3 Figure 2 "4" is recorded in the byte corresponding to transaction 6 in buffer 5 to record a pending task corresponding to transaction 6. The pending task can only be executed after transaction 4 is committed or written.

[0067] 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 can be any waiting condition triggered by a predetermined operation.

[0068] In step S304, for the multiple tasks to be processed that have been recorded in the shared memory, it is determined whether there is a task to be processed that is waiting for the process to end.

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

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

[0071] In the case that thread 3 does not find the pending task whose waiting process ends in buffer 2, thread 3 may, for example, check buffer 3. As described above, each pending task recorded in 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 may determine whether the value of k2 has been written from the predetermined address in the shared memory corresponding to transaction 2. In the case that the value of k2 has been written, it means that the waiting process of the pending task corresponding to transaction 2 has ended, wherein the predetermined address corresponds to transaction 2. The value of k2 may be written at the address by other threads that perform a read operation. In the case that it is determined that the value of k2 has not been written, it may be determined whether the waiting process has ended for the pending task after transaction 2. For example, if "k1" is recorded in the byte corresponding to transaction 3, it may be determined whether the value of k1 has been written at the predetermined address corresponding to transaction 3.

[0072] In the case that thread 3 does not find the pending tasks whose waiting process ends in buffers 2 and 3, thread 3 may check buffer 4, for example. As described above, the pending tasks recorded in buffer 4 correspond to transactions that wait for other transactions to be submitted for read operations based on the write situation. Similar to checking buffer 2, thread 3 may determine, for example, whether transaction 1, which transaction 2 is waiting for, is submitted based on the transaction window in the shared memory. In the case that it is determined that transaction 1 is submitted, the waiting process of the pending tasks corresponding to transaction 2 ends. In the case that it is determined that transaction 1 is not submitted, thread 3 may determine whether the waiting process of the pending tasks corresponding to the transactions after transaction 2 ends, for example, it may determine whether the waiting process corresponding to transaction 3 ends.

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

[0074] It can be understood that the buffers 2 to 5 included in the above-mentioned shared memory are only illustrative and not restrictive, and the above-mentioned order of checking the buffers is only illustrative and not restrictive. In a specific implementation, the buffers can be set according to the needs of the scene, and the order of checking the buffers can be set.

[0075] In one embodiment, if no pending tasks waiting for the end of the waiting process are detected in buffers 2 to 5, thread 3 may check Figure 2 The buffer 1 in the shared memory shown in FIG. 1 records the pending transactions, so that thread 3 can obtain the pending transaction with the smallest number (for example, transaction 6) from the buffer 1 and start executing the transaction.

[0076] In step S306, when it is determined that there is a second task to be processed in the shared memory waiting for the end of the process, the second task to be processed is continued to be executed based on the execution information corresponding to the second task to be processed.

[0077] In one embodiment, thread 3 obtains the second pending task whose waiting process is over in buffer 2, and thread 3 continues to submit the transaction corresponding to the second pending task based on the corresponding execution information. After determining that the waiting process of the second pending task is over, thread 3 removes the corresponding second pending task in the buffer, for example, changes the "1" corresponding to the second pending task in buffer 2 to 0.

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

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

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

[0081] Figure 4 Another aspect of the present specification shows that according to one embodiment of the present specification, there is provided a device 400 for concurrently executing transactions in a blockchain, wherein the device is deployed in a first execution body in a first node in the blockchain, wherein transactions are currently concurrently executed by a preset number of execution bodies in the first node, including the first execution body, wherein the first execution body is currently processing a first transaction, and wherein the device comprises:

[0082] The recording unit 41 is configured to, after performing a predetermined operation in the process of processing the first transaction, record a first to-be-processed task corresponding to the first transaction and execution information corresponding to the first to-be-processed task in the shared memory, so as to enter a waiting process with respect to the first transaction;

[0083] A determining unit 42 is configured to determine, for a plurality of pending tasks recorded in the shared memory, whether there is a pending task waiting for the process to end, wherein the plurality of pending tasks are recorded by the predetermined number of execution bodies; and

[0084] The continuing execution unit 43 is configured to, when it is determined that the waiting process corresponding to the second task to be processed is ended, continue to execute the second task to be processed based on the execution information corresponding to the second task to be processed, wherein the second task to be processed is included in the multiple tasks to be processed.

[0085] In one embodiment, the device further includes a transaction execution unit 44 configured to, when it is determined that the waiting processes of the plurality of tasks to be processed have not ended, obtain a second transaction to be processed from a first buffer in a shared memory and start executing the second transaction.

[0086] In one embodiment, the shared memory includes a second buffer, wherein the recording unit 41 is further configured to, after processing the first transaction, record a first to-be-processed task corresponding to the first transaction in the second buffer in the case where it is determined that the second transaction is not submitted, wherein the second transaction is a previous transaction of the first transaction according to a predetermined submission order.

[0087] In one embodiment, the determination unit 42 is further configured to determine whether the waiting process of the pending task corresponding to the smallest transaction number in the second buffer has ended based on the transaction currently to be submitted recorded in the shared memory, so as to determine whether there is a pending task in the second buffer whose waiting process has ended, wherein the transaction number corresponds to the submission order of the transaction.

[0088] In one embodiment, the continuing execution unit 43 is also configured to, in the case of determining that the waiting process of the second pending task in the second buffer is ended, continue to execute the submission of the third transaction based on the execution information corresponding to the second pending task, wherein the second pending task corresponds to the third transaction.

[0089] In one embodiment, the shared memory includes a third buffer, and the first transaction includes a read operation on a first variable, wherein the recording unit 41 is further configured to, after requesting to read the first variable, record a first to-be-processed task corresponding to the first transaction in the third buffer, wherein the first to-be-processed task includes a record of the first variable.

[0090] In one embodiment, the third buffer includes the second pending task, and the second pending task corresponds to the read operation of the second variable in the second transaction. The determination unit 42 is also configured to determine whether the variable value of the second variable is returned. In the case that it is determined that the variable value of the second variable is returned, it is determined that the waiting process of the second pending task is ended.

[0091] In one embodiment, the determination unit 42 is further configured to determine, for multiple pending tasks recorded in the third buffer, whether the waiting process of each pending task is ended in sequence based on the transaction numbers corresponding to each pending task in ascending order, wherein the second pending task is the pending task whose waiting process is determined to have ended for the first time, and wherein the transaction number corresponds to a predetermined submission order of transactions.

[0092] In one 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 predetermined address corresponds to the second transaction.

[0093] In one embodiment, the continuing execution unit 43 is also configured to, in the event that it is determined that there is a second pending task waiting for the process to end in the third buffer, continue to execute the second transaction based on the execution information corresponding to the second pending task and the variable value of the second variable.

[0094] In one embodiment, the shared memory includes a fourth buffer, and the first transaction includes a read operation on the first variable, wherein the recording unit 41 is further configured to, after executing the code for the read operation, determine whether each transaction whose submission order is before the first transaction and has not been submitted is a conflicting transaction that has executed a write operation on the first variable, wherein the transactions include a second transaction, and in the case where it is determined that the second transaction is the conflicting transaction closest to the first transaction, record a first to-be-processed task corresponding to the first transaction in the fourth buffer, wherein the first to-be-processed task includes a record of the second transaction.

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

[0096] In one embodiment, the shared memory includes a fifth buffer, and the first transaction includes a read operation on the first variable, wherein the recording unit 41 is further configured to, after executing the code for the read operation, infer whether each transaction whose submission order is before the first transaction and which has not been submitted is a conflicting transaction that will perform a write operation on the first variable, wherein the transactions include a second transaction, and in the case where it is inferred that the second transaction is the conflicting transaction closest to the first transaction, record a first to-be-processed task corresponding to the first transaction in the fifth buffer, wherein the first to-be-processed task includes a record of the second transaction.

[0097] 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, wherein the determination unit 42 is further configured to determine whether there are tasks to be processed in each buffer waiting for the process to end based on a predetermined order of the at least one buffer.

[0098] On the other hand, the present specification provides 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 perform any of the above methods.

[0099] On the other hand, the present specification provides a computing device, including a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, any of the above methods is implemented.

[0100] By implementing a solution for concurrently executing transactions according to the embodiments of the present specification, when the executor needs to wait during the process of executing a transaction, the processing information of the transaction is recorded, and other pending tasks or other pending transactions are obtained from the shared memory for processing, thereby reducing the waiting time of the executor and speeding up the overall speed of concurrent execution of transactions.

[0101] It should be understood that the descriptions such as “first” and “second” in this article are only used to distinguish similar concepts for the sake of simplicity of description and do not have any other limiting effect.

[0102] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0103] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0104] Those of ordinary skill in the art should further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described 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. Those of ordinary skill in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0105] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented by hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0106] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for concurrently executing transactions in a blockchain, the method being executed by a first execution body included in a first node in the blockchain, comprising: After performing a predetermined operation 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 a shared memory, and entering a waiting process with respect to the first transaction; For a plurality of pending tasks that have been recorded in the shared memory, determining whether there is a pending task waiting for the process to end, wherein the plurality of pending tasks are recorded by a predetermined number of execution bodies included in the first node; as well as In the case where it is determined that the waiting process corresponding to the second task to be processed is completed, the second task to be processed is continued to be executed based on the execution information corresponding to the second task to be processed.

2. The method according to claim 1 further includes, when it is determined that the waiting processes of the plurality of tasks to be processed have not ended, obtaining the second transaction to be processed from the first buffer in the shared memory and starting to execute the second transaction.

3. The method according to claim 1, wherein: The shared memory includes a second buffer, wherein after a predetermined operation is performed during processing of a first transaction, a first to-be-processed task corresponding to the first transaction and execution information corresponding to the first to-be-processed task are recorded in the shared memory, including: after processing the first transaction, in the case where it is determined that the second transaction is not submitted, the first to-be-processed task corresponding to the first transaction is recorded in the second buffer, wherein the second transaction is a previous transaction of the first transaction according to a predetermined submission order.

4. The method according to claim 3, wherein: For multiple pending tasks recorded in the shared memory, determining whether there is a pending task waiting for the end of the process includes: based on the transaction currently to be submitted recorded in the shared memory, determining whether the waiting process of the pending task corresponding to the smallest transaction number in the second buffer is ended, so as to determine whether there is a pending task waiting for the end of the process in the second buffer, wherein the transaction number corresponds to the submission order of the transactions.

5. The method according to claim 4, wherein: In the case where it is determined that the waiting process corresponding to the second pending task is ended, continuing to execute the second pending task based on the execution information corresponding to the second pending task includes: in the case where it is determined that the waiting process of the second pending task in the second buffer is ended, continuing to submit the third transaction based on the execution information corresponding to the second pending task, wherein the second pending task corresponds to the third transaction.

6. The method according to claim 1, wherein: The shared memory includes a third buffer, the first transaction includes a read operation on the first variable, wherein after performing a predetermined operation in the process of processing the first transaction, recording a first to-be-processed task corresponding to the first transaction in the shared memory, and execution information corresponding to the first to-be-processed task includes, after requesting to read the first variable, recording the first to-be-processed task corresponding to the first transaction in the third buffer, wherein the first to-be-processed task includes a record of the first variable.

7. The method according to claim 6, wherein: The third buffer includes the second pending task, which corresponds to the read operation of the second variable in the second transaction. For the multiple pending tasks recorded in the shared memory, determining whether there is a pending task waiting for the end of the process includes determining whether the variable value of the second variable is returned. When it is determined that the variable value of the second variable is returned, it is determined that the waiting process of the second pending task is ended.

8. The method according to claim 7, wherein: For multiple pending tasks that have been recorded in the shared memory, determining whether there is a pending task whose waiting process is over includes, for multiple pending tasks that have been recorded in the third buffer, determining in sequence from small to large the transaction numbers corresponding to the respective pending tasks whether the waiting process is over, wherein the second pending task is the pending task whose waiting process is determined for the first time, and wherein the transaction numbers correspond to the predetermined submission order of the transactions.

9. The method according to claim 7, wherein: 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.

10. The method according to claim 7, wherein: In the case where it is determined that the waiting process corresponding to the second pending task has ended, continuing to execute the second pending task based on the execution information corresponding to the second pending task includes: in the case where it is determined that there is a second pending task whose waiting process has ended in the third buffer, continuing to execute the second transaction based on the execution information corresponding to the second pending task and the variable value of the second variable.

11. The method according to claim 1, wherein: The shared memory includes a fourth buffer, the first transaction includes a read operation on the first variable, wherein after a predetermined operation is performed in the process of processing the first transaction, a first to-be-processed task corresponding to the first transaction is recorded in the shared memory, and execution information corresponding to the first to-be-processed task includes: after executing the code for the read operation, determining whether each transaction that is submitted before the first transaction and has not been submitted is a conflicting transaction that has executed a write operation on the first variable, the transactions include a second transaction, and in the case of determining that the second transaction is the conflicting transaction closest to the first transaction, the first to-be-processed task corresponding to the first transaction is recorded in the fourth buffer, wherein the first to-be-processed task includes a record of the second transaction.

12. The method according to claim 11, wherein: For multiple pending tasks recorded in the shared memory, determining whether there is a pending task waiting for the process to end includes, based on the current transaction to be submitted recorded in the shared memory, determining whether there is a pending task waiting for the process to end among the multiple pending tasks recorded in the fourth buffer.

13. The method according to claim 1, wherein: The shared memory includes a fifth buffer, the first transaction includes a read operation on the first variable, wherein after a predetermined operation is performed in the process of processing the first transaction, a first task to be processed corresponding to the first transaction is recorded in the shared memory, and execution information corresponding to the first task to be processed includes: after executing the code for the read operation, it is inferred whether each transaction that is submitted before the first transaction and has not been submitted is a conflicting transaction that will perform a write operation on the first variable, the transactions include a second transaction, and in the case where it is inferred that the second transaction is the conflicting transaction closest to the first transaction, the 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.

14. 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 pending task respectively. Among them, for multiple pending tasks recorded in the shared memory, determining whether there is a pending task waiting for the process to end includes, based on a predetermined order of the at least one buffer, determining whether there is a pending task waiting for the process to end in each buffer.

15. A device for concurrently executing transactions in a blockchain, the device being deployed in a first execution body in a first node in the blockchain, the device comprising: a recording unit configured to, after performing a predetermined operation in the process of processing the first transaction, record a first to-be-processed task corresponding to the first transaction and execution information corresponding to the first to-be-processed task in a shared memory, and enter a waiting process with respect to the first transaction; a determining unit configured to determine, for a plurality of pending tasks recorded in the shared memory, whether there is a pending task waiting for the process to end, wherein the plurality of pending tasks are recorded by a predetermined number of execution bodies included in the first node; as well as The continuing execution unit is configured to, when it is determined that the waiting process corresponding to the second task to be processed is completed, continue to execute the second task to be processed based on the execution information corresponding to the second task to be processed.

16. The apparatus according to claim 15 further comprises a transaction execution unit configured to, when it is determined that the waiting processes of the plurality of tasks to be processed have not ended, obtain a second transaction to be processed from a first buffer in a shared memory and start executing the second transaction.

17. The device according to claim 15, wherein: The shared memory includes a second buffer, wherein the recording unit is further configured to, after processing the first transaction, record a first to-be-processed task corresponding to the first transaction in the second buffer in the case where it is determined that the second transaction is not submitted, wherein the second transaction is a previous transaction of the first transaction according to a predetermined submission order.

18. The device according to claim 17, wherein: The determination unit is further configured to determine, based on the transaction currently to 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 has ended, so as to determine whether there is a pending task in the second buffer whose waiting process has ended, wherein the transaction number corresponds to the submission order of the transaction.

19. The device according to claim 18, wherein: The continuing execution unit is also configured to, when it is determined that the waiting process of the second pending task in the second buffer is ended, continue to execute the submission of the third transaction based on the execution information corresponding to the second pending task, wherein the second pending task corresponds to the third transaction.

20. The device according to claim 15, wherein: The shared memory includes a third buffer, and the first transaction includes a read operation on a first variable, wherein the recording unit is further configured to, after requesting to read the first variable, record a first to-be-processed task corresponding to the first transaction in the third buffer, wherein the first to-be-processed task includes a record of the first variable.

21. The device according to claim 20, wherein: The third buffer includes the second pending task, which corresponds to the read operation of the second variable in the second transaction. The determination unit is further configured to determine whether the variable value of the second variable is returned. When it is determined that the variable value of the second variable is returned, it is determined that the waiting process of the second pending task is ended.

22. The device according to claim 21, wherein The determination unit is further configured to determine, for the multiple pending tasks recorded in the third buffer, whether the waiting process of each pending task is ended in sequence based on the transaction numbers corresponding to each pending task in ascending order, wherein the second pending task is the pending task whose waiting process is determined to be ended for the first time, and wherein the transaction number corresponds to a predetermined submission order of the transaction.

23. The device 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.

24. The device according to claim 21, wherein The continuing execution unit is further configured to, when it is determined that there is a second pending task waiting for the end of the process in the third buffer, continue to execute the second transaction based on the execution information corresponding to the second pending task and the variable value of the second variable.

25. The device according to claim 15, wherein: The shared memory includes a fourth buffer, and the first transaction includes a read operation on the first variable, wherein the recording unit is further configured to, after executing the code for the read operation, determine whether each transaction that has been submitted before the first transaction and has not been submitted is a conflicting transaction that has executed a write operation on the first variable, wherein the transactions include a second transaction, and in the case where it is determined that the second transaction is the conflicting transaction closest to the first transaction, record a first to-be-processed task corresponding to the first transaction in the fourth buffer, wherein the first to-be-processed task includes a record of the second transaction.

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

27. The device according to claim 15, wherein: The shared memory includes a fifth buffer, the first transaction includes a read operation on the first variable, wherein the recording unit is further configured to, after executing the code for the read operation, infer whether each transaction that is submitted before the first transaction and has not been submitted is a conflicting transaction that will perform a write operation on the first variable, wherein the transactions include a second transaction, and in the case where it is inferred that the second transaction is the conflicting transaction closest to the first transaction, record a first to-be-processed task corresponding to the first transaction in the fifth buffer, wherein the first to-be-processed task includes a record of the second transaction.

28. 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 determination unit is further configured to determine whether there are tasks to be processed in each buffer waiting for the process to end based on a predetermined order of the at least one buffer.

29. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 14.

30. A computing device comprising a memory and a processor, characterized in that: The memory stores executable codes, and when the processor executes the executable codes, the method according to any one of claims 1 to 14 is implemented.

Images