本說明書實施例旨在提供一種更有效的同時執行交易的方案，以解決現有技術中的不足。
為實現上述目的，本說明書一個方面提供一種在區塊鏈中同時執行交易的方法，所述方法在區塊鏈中的第一節點執行，所述第一節點中預設有第一執行體，所述第一執行體目前在處理第一交易，所述方法包括：
在所述第一執行體在處理所述第一交易的過程中開始第一等待過程之後，使得所述第一執行體休眠，所述第一等待過程用於等待其它執行體完成預定操作；以及
當所述其它執行體完成所述預定操作之後，透過所述其它執行體喚醒所述第一執行體，以使得所述第一執行體繼續執行所述第一交易。
在一個實施例中，所述第一節點中還預設有第二執行體，所述第二執行體在使得所述第一執行體休眠之前為待運行狀態，所述方法還包括，在使得所述第一執行體休眠之後，透過所述第二執行體開始執行所述第一節點中的待處理的第二交易，其中，所述第二執行體在使得所述第一執行體休眠之後搶占到之前與所述第一執行體相應的CPU。
在一個實施例中，在所述第一執行體在處理所述第一交易的過程中開始第一等待過程之後，使得所述第一執行體休眠包括，在所述第一執行體處理完成所述第一交易之後，在確定第三交易未提交的情況中，使得所述第一執行體在共享記憶體中記錄其在等待第三交易的提交，之後使得所述第一執行體開始第一等待過程，其中，所述第三交易根據預定提交順序為所述第一交易的前一個交易。
在一個實施例中，所述第一節點中還預設有第三執行體，所述第三交易由第三執行體執行，其中，當所述其它執行體完成所述預定操作之後，透過所述其它執行體喚醒所述第一執行體包括，在所述第三執行體提交所述第三交易之後，透過所述第三執行體基於所述記錄喚醒所述第一執行體。
在一個實施例中，所述第一交易中包括對第一變數的讀取操作，其中，在所述第一執行體在處理所述第一交易的過程中開始第一等待過程之後，使得所述第一執行體休眠包括，在所述第一執行體請求對所述第一變數的讀取之後，使得所述第一執行體開始第一等待過程。
在一個實施例中，所述第一節點中還預設有第四執行體，其中，所述第四執行體在所述第一執行體請求對所述第一變數的讀取之後進行對所述第一變數的讀取，其中，當所述其它執行體完成所述預定操作之後，透過所述其它執行體喚醒所述第一執行體包括，當所述第四執行體在讀取到第一變數的值之後，透過所述第四執行體喚醒所述第一執行體、並將所述第一變數的值提供給第一執行體。
在一個實施例中，當所述其它執行體完成所述預定操作之後，透過所述其它執行體喚醒所述第一執行體，以使得所述第一執行體繼續執行所述第一交易包括，當所述第一等待過程結束之後，喚醒所述第一執行體，以使得所述第一執行體在搶占到CPU之後繼續執行所述第一交易。
在一個實施例中，所述第一交易中包括對第一變數的讀取操作，其中，在所述第一執行體在處理所述第一交易的過程中開始第一等待過程之後，使得所述第一執行體休眠包括，在所述第一執行體執行到所述讀取操作的代碼之後，確定提交順序在第一交易之前、且未提交的各個交易是否為已執行了對第一變數的寫入操作的衝突交易，所述各個交易中包括第四交易，在確定所述第四交易為距離第一交易最近的衝突交易的情況中，使得所述第一執行體在共享記憶體中記錄其在等待所述第四交易的提交，之後使得所述第一執行體開始第一等待過程。
在一個實施例中，當所述其它執行體完成所述預定操作之後，透過所述其它執行體喚醒所述第一執行體包括，當執行第四交易的執行緒提交第四交易之後，透過該執行緒基於所述第一執行體在共享記憶體中的記錄喚醒所述第一執行體。
在一個實施例中，所述第一交易中包括對第一變數的讀取操作，其中，在所述第一執行體在處理所述第一交易的過程中開始第一等待過程之後，使得所述第一執行體休眠包括，在所述第一執行體執行到所述讀取操作的代碼之後，推斷提交順序在第一交易之前、且未提交的各個交易是否為將要對第一變數進行寫入操作的衝突交易，所述各個交易中包括第五交易，在推斷所述第五交易為距離第一交易最近的衝突交易的情況中，使得所述第一執行體在共享記憶體中記錄其在等待第五交易的提交或者在等待第五交易進行寫入操作，之後使得所述第一執行體開始第一等待過程。
在一個實施例中，所述執行體為以下任一個：執行緒、處理、共常式。
本說明書另一方面提供一種在區塊鏈中同時執行交易的裝置，所述裝置部署在區塊鏈中的第一節點中，所述第一節點中預設有第一執行體，所述第一執行體目前在處理第一交易，所述裝置包括：
休眠單元，配置為，在所述第一執行體在處理所述第一交易的過程中開始第一等待過程之後，使得所述第一執行體休眠，所述第一等待過程用於等待其它執行體完成預定操作；以及
喚醒單元，配置為，當所述其它執行體完成所述預定操作之後，透過所述其它執行體喚醒所述第一執行體，以使得所述第一執行體繼續執行所述第一交易。
在一個實施例中，所述第一節點中還預設有第二執行體，所述第二執行體在使得所述第一執行體休眠之前為待運行狀態，所述裝置還包括，執行單元，配置為，在使得所述第一執行體休眠之後，透過所述第二執行體開始執行所述第一節點中的待處理的第二交易，其中，所述第二執行體在使得所述第一執行體休眠之後搶占到之前與所述第一執行體相應的CPU。
在一個實施例中，所述休眠單元還配置為，在所述第一執行體處理完成所述第一交易之後，在確定第三交易未提交的情況中，使得所述第一執行體在共享記憶體中記錄其在等待第三交易的提交，之後使得所述第一執行體開始第一等待過程，其中，所述第三交易根據預定提交順序為所述第一交易的前一個交易。
在一個實施例中，所述第一節點中還預設有第三執行體，所述第三交易由第三執行體執行，其中，所述喚醒單元還配置為，在所述第三執行體提交所述第三交易之後，透過所述第三執行體基於所述記錄喚醒所述第一執行體。
在一個實施例中，所述第一交易中包括對第一變數的讀取操作，其中，所述休眠單元還配置為，在所述第一執行體請求對所述第一變數的讀取之後，使得所述第一執行體開始第一等待過程。
在一個實施例中，所述第一節點中還預設有第四執行體，其中，所述第四執行體在所述第一執行體請求對所述第一變數的讀取之後進行對所述第一變數的讀取，其中，所述喚醒單元還配置為，當所述第四執行體在讀取到第一變數的值之後，透過所述第四執行體喚醒所述第一執行體、並將所述第一變數的值提供給第一執行體。
在一個實施例中，所述喚醒單元還配置為，當所述第一等待過程結束之後，喚醒所述第一執行體，以使得所述第一執行體在搶占到CPU之後繼續執行所述第一交易。
在一個實施例中，所述第一交易中包括對第一變數的讀取操作，其中，所述休眠單元還配置為，在所述第一執行體執行到所述讀取操作的代碼之後，確定提交順序在第一交易之前、且未提交的各個交易是否為已執行了對第一變數的寫入操作的衝突交易，所述各個交易中包括第四交易，在確定所述第四交易為距離第一交易最近的衝突交易的情況中，使得所述第一執行體在共享記憶體中記錄其在等待第四交易的提交，之後使得所述第一執行體開始第一等待過程。
在一個實施例中，所述喚醒單元還配置為，當執行第四交易的執行緒提交第四交易之後，透過該執行緒基於所述第一執行體在共享記憶體中的記錄喚醒所述第一執行體。
在一個實施例中，所述第一交易中包括對第一變數的讀取操作，其中，所述休眠單元還配置為，在所述第一執行體執行到所述讀取操作的代碼之後，推斷提交順序在第一交易之前、且未提交的各個交易是否為將要對第一變數進行寫入操作的衝突交易，所述各個交易中包括第五交易，在推斷所述第五交易為距離第一交易最近的衝突交易的情況中，使得所述第一執行體在共享記憶體中記錄其在等待第五交易的提交或者在等待第五交易進行寫入操作，之後使得所述第一執行體開始第一等待過程。
在一個實施例中，所述執行體為以下任一個：執行緒、處理、共常式。
本說明書另一方面提供一種電腦可讀儲存媒體，其上儲存有電腦程式，當所述電腦程式在電腦中執行時，令電腦執行上述任一項方法。
本說明書另一方面提供一種計算設備，包括記憶體和處理器，其特徵在於，所述記憶體中儲存有可執行代碼，所述處理器執行所述可執行代碼時，實現上述任一項方法。
透過根據本說明書實施例的同時執行交易的方案，在執行體執行交易過程中需要等待時進入休眠狀態，讓出CPU資源，在等待過程結束之後被喚醒以繼續執行交易，執行體在讓出CPU資源之後，其它執行體可搶占該CPU以處理其它的交易，從而提高了CPU的利用率，加快了交易同時執行的總體速度。The embodiments of the present specification aim to provide a more effective solution for executing transactions at the same time to solve the deficiencies in the prior art.
To achieve the above objective, one aspect of this specification provides a method for simultaneously executing transactions in a blockchain, the method is executed on a first node in the blockchain, and a first executor is preset in the first node, The first executive body is currently processing the first transaction, and the method includes:
After the first executor starts a first waiting process in the process of processing the first transaction, putting the first executor to sleep, the first waiting process is used to wait for other executors to complete a predetermined operation; and
After the other executor completes the predetermined operation, the first executor is awakened through the other executor, so that the first executor continues to execute the first transaction.
In an embodiment, a second executor is also preset in the first node, and the second executor is in a standby state before the first executor is put to sleep, and the method further includes: After the first executor is hibernated, the second transaction to be processed in the first node is started to be executed through the second executor, wherein the second executor is after the first executor is hibernated The previous CPU corresponding to the first executive body is preempted.
In one embodiment, after the first executor starts the first waiting process in the process of processing the first transaction, putting the first executor to sleep includes: After the first transaction, when it is determined that the third transaction has not been submitted, the first executor is made to record in the shared memory that it is waiting for the submission of the third transaction, and then the first executor is made to start the first transaction. The waiting process, wherein the third transaction is the previous transaction of the first transaction according to a predetermined submission order.
In one embodiment, a third executor is also preset in the first node, and the third transaction is executed by the third executor, wherein, after the other executor completes the predetermined operation, The other executive body waking up the first executive body includes, after the third executive body submits the third transaction, awakening the first executive body based on the record through the third executive body.
In one embodiment, the first transaction includes a read operation of the first variable, wherein, after the first executor starts the first waiting process in the process of processing the first transaction, the The dormancy of the first executor includes, after the first executor requests to read the first variable, causing the first executor to start a first waiting process.
In one embodiment, a fourth executor is also preset in the first node, wherein the fourth executor performs a check after the first executor requests to read the first variable. The reading of the first variable, wherein, after the other executor completes the predetermined operation, waking up the first executor through the other executor includes, when the fourth executor is read After the value of a variable, wake up the first executor through the fourth executor, and provide the value of the first variable to the first executor.
In one embodiment, after the other execution body completes the predetermined operation, waking up the first execution body through the other execution body so that the first execution body continues to execute the first transaction includes: After the first waiting process ends, the first executive body is awakened, so that the first executive body continues to execute the first transaction after preempting the CPU.
In one embodiment, the first transaction includes a read operation of the first variable, wherein, after the first executor starts the first waiting process in the process of processing the first transaction, the The dormancy of the first executor includes, after the first executor executes the code to the read operation, determining whether each transaction whose submission sequence is before the first transaction and has not been submitted has been executed for the first variable Conflict transactions of the write operation, each of the transactions includes a fourth transaction, in the case of determining that the fourth transaction is the closest conflict transaction to the first transaction, make the first executive body in the shared memory It is recorded that it is waiting for the submission of the fourth transaction, and then the first executive body is caused to start the first waiting process.
In one embodiment, after the other execution body completes the predetermined operation, waking up the first execution body through the other execution body includes, after the thread that executes the fourth transaction submits the fourth transaction, through the The thread wakes up the first executor based on the record of the first executor in the shared memory.
In one embodiment, the first transaction includes a read operation of the first variable, wherein, after the first executor starts the first waiting process in the process of processing the first transaction, the The dormancy of the first executor includes, after the first executor executes the code of the read operation, inferring whether each transaction whose submission sequence is before the first transaction and is not submitted is about to write the first variable Enter the conflicting transaction of the operation, each of the transactions includes a fifth transaction, and in the case that the fifth transaction is inferred to be the conflicting transaction closest to the first transaction, the first executive body is made to record it in the shared memory After waiting for the submission of the fifth transaction or waiting for the fifth transaction to perform the write operation, the first executive body is then caused to start the first waiting process.
In an embodiment, the executive body is any one of the following: thread, processing, and common routine.
Another aspect of this specification provides a device for simultaneously executing transactions in a blockchain. The device is deployed in a first node in the blockchain, and a first executor is preset in the first node. An executive is currently processing the first transaction, and the device includes:
The dormant unit is configured to, after the first executor starts a first waiting process in the process of processing the first transaction, put the first executor to sleep, and the first waiting process is used to wait for other executions The body completes the scheduled operation; and
The awakening unit is configured to wake up the first executor through the other executor after the other executor completes the predetermined operation, so that the first executor continues to execute the first transaction.
In an embodiment, a second executor is preset in the first node, and the second executor is in a standby state before the first executor is put to sleep, and the device further includes an execution unit , Configured to, after making the first executor dormant, start to execute the second transaction to be processed in the first node through the second executor, wherein the second executor is making the After the first executive body sleeps, it preempts the previous CPU corresponding to the first executive body.
In one embodiment, the dormant unit is further configured to, after the first transaction is completed by the first executor, in the case where it is determined that the third transaction has not been submitted, the first executor is shared It is recorded in the memory that it is waiting for the submission of the third transaction, and then the first executor starts the first waiting process, wherein the third transaction is the previous transaction of the first transaction according to a predetermined submission order.
In one embodiment, a third executor is also preset in the first node, and the third transaction is executed by the third executor, wherein the wake-up unit is further configured to: After submitting the third transaction, wake up the first executor based on the record through the third executor.
In one embodiment, the first transaction includes a reading operation of the first variable, wherein the sleep unit is further configured to, after the first executor requests the reading of the first variable , So that the first executive body starts the first waiting process.
In one embodiment, a fourth executor is also preset in the first node, wherein the fourth executor performs a check after the first executor requests to read the first variable. In the reading of the first variable, the awakening unit is further configured to wake up the first executor through the fourth executor after the fourth executor reads the value of the first variable And provide the value of the first variable to the first executive body.
In one embodiment, the awakening unit is further configured to wake up the first executive body after the first waiting process ends, so that the first executive body continues to execute the first executive body after preempting the CPU. One transaction.
In an embodiment, the first transaction includes a read operation of the first variable, wherein the sleep unit is further configured to, after the first executive body executes the code to the read operation, Determine whether each transaction whose submission sequence is before the first transaction and not submitted is a conflict transaction in which the write operation to the first variable has been performed, the each transaction includes a fourth transaction, and it is determined that the fourth transaction is In the case of the conflicting transaction closest to the first transaction, the first executor is caused to record in the shared memory that it is waiting for the submission of the fourth transaction, and then the first executor is caused to start the first waiting process.
In one embodiment, the awakening unit is further configured to, after the thread that executes the fourth transaction submits the fourth transaction, wake up the first executor based on the record of the first executor in the shared memory through the thread One executive body.
In an embodiment, the first transaction includes a read operation of the first variable, wherein the sleep unit is further configured to, after the first executive body executes the code to the read 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. The each transaction includes the fifth transaction, and it is inferred that the fifth transaction is the first one. In the case of the most recent conflicting transaction of a transaction, the first executor is made to record in the shared memory that it is waiting for the submission of the fifth transaction or is waiting for the fifth transaction to perform the write operation, and then the first executor is made Start the first waiting process.
In an embodiment, the executive body is any one of the following: thread, processing, and common routine.
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 made to execute any of the above methods.
Another aspect of this specification provides a computing device, including a memory and a processor, characterized in that executable code is stored in the memory, and when the processor executes the executable code, any one of the above methods is implemented .
Through the solution of executing transactions at the same time according to the embodiment of this specification, the executive body enters the dormant state when it needs to wait during the execution of the transaction, and gives up CPU resources. After the waiting process is over, the executive body is awakened to continue executing the transaction. After the resources, other executive bodies can preempt the CPU to process other transactions, thereby improving the utilization of the CPU and speeding up the overall speed of simultaneous execution of transactions.
下面將結合附圖描述本說明書實施例。
圖1示出根據本說明書實施例的區塊鏈系統示意圖。如圖1所示，所述系統中包括構成區塊鏈的多個節點（圖中示意示出6個節點），這些節點兩兩相連，其中例如包括節點11、節點12和節點13。如本領域技術人員所知，在區塊鏈中，一些節點會收集區塊鏈中的多個交易放入交易池中並競爭記帳權。例如圖中的節點11透過獲取記帳權而成為記帳節點。節點11在成為記帳節點之後會執行其交易池中的多個交易，並將該多個交易打包成區塊發送給其它節點，例如發送給節點12。節點12將會對該區塊進行驗證，並同樣地執行該區塊中的多個交易。在預定數目個節點對該區塊進行驗證之後，也即對該區塊達到了共識，區塊鏈中的其它節點（例如節點13）將不需要繼續對該區塊進行驗證，而是直接對該區塊中的交易進行執行，以更新本地的相關資料。
圖2示出在區塊鏈中各個節點透過多個執行緒同時執行交易的示意圖。可以理解，所述執行緒也可以替換為處理、共常式等執行體。如圖2中所示，在每個節點中，通常，CPU的數目是有限的，預設的執行緒的數目也是固定的，例如，假設該節點的CPU數為4個，執行緒池中預設的執行緒數目為6個，從而6個執行緒競爭搶占CPU，並且只有在搶占到CPU之後，才能開始執行任務池中的任務。
在多個執行緒同時執行多個交易的過程中，所述多個交易中可能涉及到對多個變數的計算，在兩個交易中不涉及相同的變數的情況中，其執行順序並不會影響最終的計算結果，而在兩個交易中涉及相同的變數的情況中，其執行順序將會影響最終的計算結果。在本說明書實施例中，為了保證各個節點對多個交易的執行結果是相同的，在同時執行多個交易的同時，考慮交易之間對存取變數的衝突，從而使得平行執行的執行緒中的一些執行緒需要經過等待過程。或者在等待返回存取儲存時需要進行等待。
如圖2中所示，該圖中包括第一節點的共享記憶體，該共享記憶體中例如包括用於指示待處理交易的第一緩衝區（緩衝區1），該共享記憶體是相對於全部執行緒可讀寫的。例如，第一緩衝區中目前記錄了10個待處理的交易1、2、…10，其中，圖中數字1、2、…、10對應的位元框中初始應都為1，表示，其都是待處理的交易，其中，交易1～10的編號對應於各個交易的提交順序。在開始同時執行交易之後，例如，執行緒1～4分別搶占到CPU1～4，從而，執行緒1～4可分別從第一緩衝區中獲取一個任務進行處理，例如，執行緒1～4分別開始處理交易1～4，執行緒1～4在開始處理交易1～4之後，分別將第一緩衝區中交易1～4對應的位元分別修改為0，以表示這些交易已經開始執行。可以理解，雖然圖中示意示出，執行緒1搶占到CPU1，並執行交易1，執行緒2搶占到CPU2，並執行交易2等等，可以理解，圖中所示內容僅是為了示意說明，執行緒的編號、CPU的編號和交易的編號並不是相互對應的，例如，執行緒1有可能搶占到CPU2，執行交易3等等。
在本說明書實施例中，為了同時執行交易，執行交易的過程包括處理交易的過程和提交交易的過程，其中，所述處理交易的過程是將處理交易的結果儲存到與該交易對應的緩衝區中，所述提交交易的過程是將最終的處理結果儲存到各個交易共用的共享記憶體中。例如，執行緒3在處理完成交易3之後需要等待交易2提交完成，然後再提交交易3。圖2中的共享記憶體中還包括第二緩衝區（緩衝區2），用於記錄處理完成等待提交的交易及相應的執行緒。另外，執行緒3還具有屬於其自身的第三緩衝區，用於儲存交易執行信息。在執行緒3執行到該等待過程時，也就是說，當執行緒3處理完交易3之後，執行緒3在第三緩衝區中保存與交易3對應的目前執行信息，在第二緩衝區中將與交易3對應的位元組修改為3（表示執行緒3），表示其已處理完交易3並等待提交，之後進入休眠狀態，以讓出其搶占的CPU（即圖中CPU3）。執行緒3在讓出CPU3之後，剩下的待運行的執行緒（執行緒5和執行緒6）可進行對CPU資源的競爭，例如執行緒5搶占到該CPU3，從而執行緒5可以到第一緩衝區中獲取排在最前面的一個待處理交易（交易5）進行交易執行。執行緒2在提交完成交易2之後，查看第二緩衝區，當其發現第二緩衝中的與交易3對應的位元組為3時，相應地喚醒執行緒3。執行緒3在被喚醒之後，可進行對CPU的競爭，在搶占到CPU之後，可從第三緩衝區（緩衝區3）中獲取與交易3對應的執行信息，並基於該執行信息開始進行對交易3的提交過程。
可以理解，上文對圖2的描述只是示意性地，而不是用於限制本說明書實施例的範圍。例如，所述等待過程不一定為上述等待前一個交易提交的過程，所述第一緩衝區、第二緩衝區和第三緩衝區的具體形式不一定為圖中所示形式，只要其能記錄下相應的信息即可。下文將詳細描述上述同時執行交易的過程。
圖3示出根據本說明書實施例的一種在區塊鏈中同時執行交易的方法流程圖，所述方法在區塊鏈中的第一節點執行，所述第一節點中預設有第一執行體，所述第一執行體目前在執行第一交易，所述第一交易中包括第一等待過程，所述方法包括：
在步驟S302，在所述第一執行體在處理所述第一交易的過程中開始第一等待過程之後，使得所述第一執行體休眠，所述第一等待過程用於等待其它執行體完成預定操作；以及
在步驟S304，當所述其它執行體完成所述預定操作之後，透過所述其它執行體喚醒所述第一執行體，以使得所述第一執行體繼續執行所述第一交易。
首先，在步驟S302，在所述第一執行體在處理所述第一交易的過程中開始第一等待過程之後，使得所述第一執行體休眠，所述第一等待過程用於等待其它執行體完成預定操作。
如上文中參考圖2所述，所述第一執行體例如可以為執行緒、處理、共常式等執行主體。下文中將以執行緒為例進行說明。
在節點中同時執行交易的過程中，對於其中一個正在執行的交易，可能會包括多個等待過程，所述等待過程可能是由於不同的原因引起的。
在一個實施例中，如上文中參考圖2中所述，所述多個同時執行的交易已經預設了預定的提交順序，例如圖2中的交易1～10必須按照其編號的從小到大的順序進行先後提交，以保證各個節點對該多個交易的執行結果是相同的。這裡，在節點中，執行緒在執行交易時，將交易處理結果先保存到僅與該交易對應的緩衝區中，而在提交之後，才將該處理結果保存到各個交易共用的共享記憶體中。例如，在處理第一交易的過程中，需要對第一變數進行寫入操作，則在僅與第一交易對應的緩衝區中先保存該寫入操作之後的第一變數的值，該值僅在處理該第一交易時可以使用，在處理其它交易時並不會對該值進行讀寫。而在提交第一交易之後，第一交易的值被存到共享記憶體中，其它交易也可以讀取到該值，或者透過提交對該值進行修改。
由於各個交易具有預定的提交順序，因此，如圖2中所示，例如所述第一交易為圖2中的交易3，則第一執行體為圖中的執行緒3。如果在執行緒2提交交易2之前，執行緒3先處理完交易3，此時，執行緒3需要等待執行緒2提交完成之後才能進行對交易3的提交。從而，為了不浪費CPU資源，可以使得執行緒3進入休眠狀態，以使得其它待運行執行緒透過搶占該讓出的CPU，繼續執行其它待處理的交易，這樣就充分利用了CPU資源，提高了同時執行交易的速度。執行緒3在休眠之前需要留下信號，以使得交易2在提交之後，相應的執行交易2的執行緒（即執行緒2）會知道執行緒3在等交易2的提交、並且執行緒3為休眠狀態。如圖2中所示，例如，可在共享記憶體中設置第二緩衝區（緩衝區2），第二緩衝區用於記錄這樣的情況。第二緩衝區包括與各個交易對應的位元組，並且每個位元組的初始值為0。例如，執行緒3在執行完成交易3之後將第二緩衝區中與交易3對應的位元組從0修改為3，從而記錄執行緒3已經執行完交易3，在等待交易2提交，並且即將休眠。可以理解，執行緒3不限於透過這種方式留下信號，例如，執行緒3可在與交易2對應的記憶體中進行該記錄，或者執行緒3可透過字元串的方式進行該記錄等等。執行緒3在進行完上述記錄之後，進入等待過程，在進入等待過程之後，執行緒3透過預定指令進入休眠狀態，以進行等待。
在一個實施例中，例如，圖2中的交易3包括對變數k1的讀取操作。所述第一節點中預設有專用於進行儲存存取的硬體（如CPU、FPGA等等）。執行緒3在開始執行該讀取操作之後，請求所述硬體執行對k1的讀取，並在進行該請求之後進行等待，從而，執行緒3可在所述請求之後進入休眠狀態。所述硬體接收到該請求之後，記錄下執行緒3的該請求，透過其中的一個執行緒（例如執行緒11）從共享記憶體中的變數表中讀取k1的值。
在一個實施例中，各個執行緒在執行交易且未提交該交易時，將對變數的讀、寫操作記錄到共享記憶體中。例如，執行緒1在進行交易1中對變數k1的寫入操作之後，在共享記憶體中的變數寫表的與k1對應的位元中進行標記，執行緒3在將要讀取k1之前，查詢所述變數寫表，當其發現交易1進行了對k1的寫入操作、且交易2還未進行對k1的寫入操作之後，由於執行緒3只有在交易1提交之後才能讀取到該寫入操作對應的值，因此，執行緒3需要等待交易1提交之後，再進行對變數k1的讀取，從而，執行緒3在執行到所述讀取操作的代碼之後查詢該變數寫表，並基於查詢結果在共享記憶體中的與第二緩衝區類似的緩衝區中記錄其在等待交易1的提交，然後進入休眠狀態，以進行等待。
在一個實施例中，交易3中包括對變數k1的讀取操作，執行緒3在開始該讀取操作之後，推斷正在同時執行的多個交易中提交順序在交易3之前的各個交易（例如圖2中的交易1～2）是否將要對變數k1進行寫入操作。在一個實施例中，執行緒3可基於第一節點中的歷史計算資料（交易執行歷史），確定變數k1的交易衝突機率，如果該衝突機率大於預定臨限值，則可推斷交易1和交易2都將要對k1進行寫入操作，從而，執行緒3可以在共享記憶體中與第二緩衝區類似的緩衝區中記錄其在等待交易2的提交，然後進入休眠狀態，以等待交易2提交完成再進行對k1的讀取。或者，如果交易2在處理過程中將對k1的寫入值寫入共享記憶體中與交易2對應的緩衝區（該緩衝區不是與各個交易對應的變數表）中，則可等待交易2執行完k1的寫入後，進行對k1的讀取。在一個實施例中，交易3可基於前面各個交易的交易資料，確定其與前面各個交易的衝突機率，並基於該衝突機率，推斷所述各個交易是否將要對k1進行寫入操作，從而確定是否在進行讀取操作之前進入休眠狀態，以進行等待。例如，在確定交易1對k1的寫入機率大於等於預定臨限值、且交易2對k1的寫入機率小於預定臨限值的情況中，執行緒3在所述緩衝區5中記錄其在等待交易1的提交或寫入，然後進入等待過程，即進入休眠狀態。
在步驟S304，當所述其它執行體完成所述預定操作之後，透過所述其它執行體喚醒所述第一執行體，以使得所述第一執行體繼續執行所述第一交易。
在上述交易3在執行完成之後等待交易2的提交的實施例中，執行緒2在提交完成交易2之後，會查詢第二緩衝區，以確定執行緒3是否在等它。當執行緒2發現第二緩衝區中與交易3對應的位元組為3的情況中，執行緒2知道執行緒3目前為休眠狀態，因此，執行緒2喚醒執行緒3，以使得執行緒3可以繼續執行交易3。執行緒3在被喚醒之後，可將第二緩衝區中的“3”修改為0，以指示執行緒3已被喚醒。執行緒3在被喚醒之後首先是處於待運行狀態，其將與其它的空閒執行緒一起競爭CPU，等執行緒3搶占到CPU之後，其可以開始進行對交易3的提交。在進行交易3的提交之前，執行緒3可以先查詢一下，根據在前提交的交易的記錄，確定交易3是否需要重做，在不需要重做的情況下，執行緒3可以提交交易3。在該第一節點中還可能設置了交易窗口，透過該交易窗口控制可同時同時執行的交易的最大總數，該交易窗口的兩邊分別是目前同時執行的編號最小的交易和編號最大的交易。從而，執行緒3在提交交易3之後，還可以將交易窗口中的編號最小交易修改為4。
在執行緒3等待其它執行緒（執行緒11）返回變數讀取值的實施例中，執行緒11在讀取到變數k1的值之後，其根據硬體中對所述請求的記錄，喚醒執行緒3，並將該讀取到的值提供（例如，發送）給執行緒3，從而執行緒3可同樣地在搶占到CPU之後，基於從執行緒11獲取的變數k1的值繼續執行該交易3。可以理解，這裡不一定透過執行緒11將所述讀取的值發送給執行緒3，例如，執行緒11在讀取到k1的值之後，可將k1的值存到預定位址，從而執行緒3在被喚醒之後可在該預定位址獲取該k1的值。
在執行緒3基於變數寫表等待交易1的相應操作以進行對k1的讀取操作的實施例中，執行緒3可與上述第一個實施例類似地，透過記錄一個信號而使得執行緒1在執行了相應操作之後喚醒執行緒3。例如，執行緒3可在與該場景對應的（共享的或僅對應於交易1的）緩衝區中記錄其在等交易1提交。從而，執行緒1在提交交易1之後，會查詢該緩衝區，並基於執行緒3的記錄喚醒執行緒3，從而使得執行緒3在搶占到CPU之後可以繼續執行對k1的讀取操作。
在執行緒3基於衝突機率等待交易2的相應操作以繼續對變數k1的讀取的實施例中，執行緒3可與上述實施例類似地，透過記錄一個信號而使得執行緒2在執行了相應操作之後喚醒執行緒3。例如，執行緒3可在與該場景對應的（共享的或僅對應於交易2的）緩衝區中記錄其在等交易2提交。從而，執行緒2在提交交易2之後，會查詢該緩衝區，並基於執行緒3的記錄喚醒執行緒3，從而使得執行緒3在搶占到CPU之後可以繼續執行對k1的讀取操作。
圖4示出根據本說明書一個實施例的一種在區塊鏈中同時執行交易的裝置400，所述裝置部署在區塊鏈中的第一節點中，所述第一節點中預設有第一執行體，所述第一執行體目前在處理第一交易，所述裝置包括：
休眠單元41，配置為，在所述第一執行體在處理所述第一交易的過程中開始第一等待過程之後，使得所述第一執行體休眠，所述第一等待過程用於等待其它執行體完成預定操作；以及
喚醒單元42，配置為，當所述其它執行體完成所述預定操作之後，透過所述其它執行體喚醒所述第一執行體，以使得所述第一執行體繼續執行所述第一交易。
在一個實施例中，所述第一節點中還預設有第二執行體，所述第二執行體在使得所述第一執行體休眠之前為待運行狀態，所述裝置還包括，執行單元43，配置為，在使得所述第一執行體休眠之後，透過所述第二執行體開始執行所述第一節點中的待處理的第二交易，其中，所述第二執行體在使得所述第一執行體休眠之後搶占到之前與所述第一執行體相應的CPU。
在一個實施例中，所述休眠單元41還配置為，在所述第一執行體處理完成所述第一交易之後，在確定第三交易未提交的情況中，使得所述第一執行體在共享記憶體中記錄其在等待第三交易的提交，之後使得所述第一執行體開始第一等待過程，其中，所述第三交易根據預定提交順序為所述第一交易的前一個交易。
在一個實施例中，所述第一節點中還預設有第三執行體，所述第三交易由第三執行體執行，其中，所述喚醒單元42還配置為，在所述第三執行體提交所述第三交易之後，透過所述第三執行體基於所述記錄喚醒所述第一執行體。
在一個實施例中，所述第一交易中包括對第一變數的讀取操作，其中，所述休眠單元41還配置為，在所述第一執行體請求對所述第一變數的讀取之後，使得所述第一執行體開始第一等待過程。
在一個實施例中，所述第一節點中還預設有第四執行體，其中，所述第四執行體在所述第一執行體請求對所述第一變數的讀取之後進行對所述第一變數的讀取，其中，所述喚醒單元42還配置為，當所述第四執行體在讀取到第一變數的值之後，透過所述第四執行體喚醒所述第一執行體、並將所述第一變數的值提供給第一執行體。
在一個實施例中，所述喚醒單元42還配置為，當所述第一等待過程結束之後，喚醒所述第一執行體，以使得所述第一執行體在搶占到CPU之後繼續執行所述第一交易。
在一個實施例中，所述第一交易中包括對第一變數的讀取操作，其中，所述休眠單元41還配置為，在所述第一執行體執行到所述讀取操作的代碼之後，確定提交順序在第一交易之前、且未提交的各個交易是否為已執行了對第一變數的寫入操作的衝突交易，所述各個交易中包括第四交易，在確定所述第四交易為距離第一交易最近的衝突交易的情況中，使得所述第一執行體在共享記憶體中記錄其在等待第四交易的提交，之後使得所述第一執行體開始第一等待過程。
在一個實施例中，所述喚醒單元42還配置為，當執行第四交易的執行緒提交第四交易之後，透過該執行緒基於所述第一執行體在共享記憶體中的記錄喚醒所述第一執行體。
在一個實施例中，所述第一交易中包括對第一變數的讀取操作，其中，所述休眠單元41還配置為，在所述第一執行體執行到所述讀取操作的代碼之後，推斷提交順序在第一交易之前、且未提交的各個交易是否為將要對第一變數進行寫入操作的衝突交易，所述各個交易中包括第五交易，在推斷所述第五交易為距離第一交易最近的衝突交易的情況中，使得所述第一執行體在共享記憶體中記錄其在等待第五交易的提交或者在等待第五交易進行寫入操作，之後使得所述第一執行體開始第一等待過程。
本說明書另一方面提供一種電腦可讀儲存媒體，其上儲存有電腦程式，當所述電腦程式在電腦中執行時，令電腦執行上述任一項方法。
本說明書另一方面提供一種計算設備，包括記憶體和處理器，其特徵在於，所述記憶體中儲存有可執行代碼，所述處理器執行所述可執行代碼時，實現上述任一項方法。
透過根據本說明書實施例的同時執行交易的方案，在執行體執行交易過程中需要等待時進入休眠狀態，讓出CPU資源，在等待過程結束之後被喚醒以繼續執行交易，執行體在讓出CPU資源之後，其它執行體可搶占該CPU以處理其它的交易，從而提高了CPU的利用率，加快了交易同時執行的總體速度。
需要理解，本文中的“第一”，“第二”等描述，僅僅為了描述的簡單而對相似概念進行區分，並不具有其他限定作用。
本說明書中的各個實施例均採用漸進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於系統實施例而言，由於其基本相似於方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在附圖中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多任務處理和平行處理也是可以的或者可能是有利的。
本領域普通技術人員應該還可以進一步意識到，結合本文中所公開的實施例描述的各示例的單元及演算法步驟，能夠以電子硬體、電腦軟體或者二者的結合來實現，為了清楚地說明硬體和軟體的可互換性，在上述說明中已經按照功能一般性地描述了各示例的組成及步驟。這些功能究竟以硬體還是軟體方式來執行，取決於技術方案的特定應用和設計約束條件。本領域普通技術人員可以對每個特定的應用來使用不同方法來實現所描述的功能，但是這種實現不應認為超出本申請的範圍。
結合本文中所公開的實施例描述的方法或演算法的步驟可以用硬體、處理器執行的軟體模組，或者二者的結合來實施。軟體模組可以置於隨機記憶體（RAM）、記憶體、唯讀記憶體（ROM）、電可編程ROM、電可抹除可編程ROM、暫存器、硬碟、可移動磁碟、CD-ROM、或技術領域內所公知的任意其它形式的儲存媒體中。
以上所述的具體實施方式，對本發明的目的、技術方案和有益效果進行了進一步詳細說明，所應理解的是，以上所述僅為本發明的具體實施方式而已，並不用於限定本發明的保護範圍，凡在本發明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。
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 forming 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 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 a billing 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 have verified the block, that is, the block has reached a consensus, other nodes in the blockchain (such as node 13) will not need to continue to verify the block, but directly The transaction in this block is executed to update the local relevant information.
Figure 2 shows a schematic diagram of each node in the blockchain simultaneously executing transactions through multiple threads. It can be understood that the execution threads can also be replaced with execution bodies such as processing and common routines. 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 on the node is 4, the number of CPUs in the thread pool is pre-defined. Suppose the number of threads is 6, so that 6 threads compete to preempt the CPU, and only after preempting the CPU, can the tasks in the task pool begin to be executed.
When multiple threads execute multiple transactions at the same time, the multiple transactions may involve the calculation of multiple variables. In the case where 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 embodiment 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 at the same time, the conflict between the access variables between the transactions is considered, so that the parallel execution threads are Some of the threads need to go through a waiting process. Or you need to wait while waiting to return to access storage.
As shown in Figure 2, the figure includes the shared memory of the first node. The shared memory includes, for example, a first buffer (buffer 1) for indicating transactions to be processed. The shared memory is relative to All threads are readable and writable. For example, there are currently 10 pending transactions 1, 2,...10 recorded in the first buffer, among which the bit boxes corresponding to the numbers 1, 2,..., 10 in the figure should all be 1, indicating that their They are all pending transactions, where the serial numbers of transactions 1-10 correspond to the order of submission of each transaction. After the simultaneous execution of the transaction is started, for example, threads 1 to 4 are preempted to 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 respectively Start to process transactions 1 to 4. After the threads 1 to 4 start to process transactions 1 to 4, they respectively modify the bits corresponding to 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 thread 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.
In the embodiment of this specification, in order to execute the transaction at the same time, the process of executing the transaction includes the process of processing the transaction and the process of submitting the transaction, wherein 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 a shared memory shared by each transaction. For example, the thread 3 needs to wait for the completion of the transaction 2 submission after processing the transaction 3, and then submit the transaction 3. The shared memory in Fig. 2 also includes a second buffer (buffer 2), which is used to record the transaction and the corresponding thread after the processing is completed and waiting to be submitted. In addition, the thread 3 also has its own third buffer for storing transaction execution information. When thread 3 executes to the waiting process, that is, after thread 3 has processed transaction 3, thread 3 saves the current execution information corresponding to transaction 3 in the third buffer, and in the second buffer Modify the byte corresponding to transaction 3 to 3 (indicating thread 3), which means that it has processed transaction 3 and is waiting for submission, and then enters the dormant state to let go of its preempted CPU (that is, CPU3 in the figure). After thread 3 gives up CPU3, the remaining threads to run (thread 5 and thread 6) can compete for CPU resources. For example, thread 5 preempts the CPU3, so that thread 5 can go to the first thread. Get the top pending transaction (transaction 5) in a buffer for transaction execution. After the thread 2 submits and completes the transaction 2, it checks the second buffer, and when it finds that the byte corresponding to the transaction 3 in the second buffer is 3, it wakes up the thread 3 accordingly. After the thread 3 is awakened, it can compete for the CPU. After preempting the CPU, it can obtain the execution information corresponding to transaction 3 from the third buffer (buffer 3), and start the pairing based on the execution information. The submission process of transaction 3.
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 waiting process is not necessarily the aforementioned process of waiting for the submission of the previous transaction, and the specific forms of the first buffer, second buffer, and third buffer are not necessarily the forms shown in the figure, as long as they can record Just download the corresponding information. Hereinafter, the above-mentioned simultaneous execution transaction process will be described in detail.
Fig. 3 shows a flow chart of a method for simultaneously 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 execution Body, the first execution body is currently executing a first transaction, the first transaction includes a first waiting process, and the method includes:
In step S302, after the first executor starts a first waiting process in the process of processing the first transaction, the first executor is put to sleep, and the first waiting process is used to wait for the completion of other executors Scheduled operation; and
In step S304, after the other executor completes the predetermined operation, the first executor is awakened through the other executor, so that the first executor continues to execute the first transaction.
First, in step S302, after the first executor starts a first waiting process in the process of processing the first transaction, the first executor is put to sleep, and the first waiting process is used to wait for other executions. The body completes the scheduled operation.
As described above with reference to FIG. 2, the first executive body may be, for example, an execution body such as thread, processing, and common routine. The following will take the thread as an example for description.
In the process of simultaneously executing transactions in the 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 FIG. 2, the multiple simultaneous transactions have a predetermined submission sequence. For example, transactions 1 to 10 in FIG. 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 transaction processing result is first saved in the buffer corresponding to the transaction, and after submission, the processing 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 saved in the buffer corresponding to only the first transaction. The value is only It can be used when processing 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 3 in FIG. 2, and the first executive body is thread 3 in the figure. If thread 3 finishes processing transaction 3 before thread 2 submits transaction 2, then thread 3 needs to wait for thread 2 to submit before submitting transaction 3. Therefore, in order not to waste CPU resources, thread 3 can be put into a dormant state, so that other pending threads can continue to execute other pending transactions by preempting the surrendered CPU, thus making full use of CPU resources and improving The speed of executing transactions at the same time. Thread 3 needs to leave a signal before hibernation, so that after transaction 2 is submitted, the corresponding thread that executes transaction 2 (ie thread 2) will know that thread 3 is waiting for the submission of transaction 2, and thread 3 is Sleep state. As shown in FIG. 2, for example, a second buffer (buffer 2) can be set in the shared memory, and the second buffer is used to record such a situation. The second buffer area includes bytes corresponding to each transaction, and the initial value of each byte is 0. For example, thread 3 changes the byte corresponding to transaction 3 in the second buffer from 0 to 3 after executing transaction 3, thereby recording that thread 3 has completed transaction 3 and is waiting for transaction 2 to be submitted, and is about to Hibernate. It can be understood that thread 3 is not limited to leaving a signal in this way. For example, thread 3 can record the record in the memory corresponding to transaction 2, or thread 3 can record the record through a string, etc. Wait. After the above-mentioned recording is completed, the thread 3 enters the waiting process. After entering the waiting process, the thread 3 enters the dormant state through a predetermined command to wait.
In one embodiment, for example, transaction 3 in FIG. 2 includes a read operation on the variable k1. The first node is preset with hardware dedicated to storage and access (such as CPU, FPGA, etc.). After the thread 3 starts to execute the read operation, it requests the hardware to execute the read of k1, and waits after making the request, so that the thread 3 can enter the sleep state after the request. After the hardware receives the request, it records the request of the thread 3, and reads the value of k1 from the variable table in the shared memory through one of the threads (eg, thread 11).
In one embodiment, when each thread executes a transaction and does not submit the transaction, it records the read and write operations on the variables into the shared memory. For example, after thread 1 writes variable k1 in transaction 1, it marks the bit corresponding to k1 in the variable write table in the shared memory, and thread 3 queries before reading k1. The variable writing table, when it finds that transaction 1 has performed a write operation to k1, and transaction 2 has not yet performed a write operation to k1, because thread 3 can only read the write operation after transaction 1 is submitted Enter the value corresponding to the operation. Therefore, thread 3 needs to wait for transaction 1 to be submitted before reading the variable k1. Therefore, thread 3 queries the variable write table after executing the code of the read operation, and Based on the query result, it is recorded in a buffer similar to the second buffer in the shared memory that it is waiting for the submission of transaction 1, and then enters the dormant state to wait.
In one embodiment, transaction 3 includes a read operation on the variable k1, and after the execution thread 3 starts the read operation, it infers that among the multiple transactions that are being executed at the same time, each transaction whose submission order is before transaction 3 (for example, FIG. Transaction 1～2 in 2) Whether to write the variable k1. In one embodiment, thread 3 can determine the transaction conflict probability of variable k1 based on historical calculation data (transaction execution history) in the first node. If the conflict probability is greater than a predetermined threshold, then it can be inferred that transaction 1 and transaction 2 are about to write to k1, so that thread 3 can record in a buffer similar to the second buffer in the shared memory that it is waiting for transaction 2 to be submitted, and then enter the dormant state to wait for transaction 2 to be submitted Finish reading k1 again. Or, if transaction 2 writes the value written to k1 into the buffer corresponding to transaction 2 in the shared memory during processing (the buffer is not the variable table corresponding to each transaction), then you can wait for transaction 2 to execute After writing k1, read k1. In one embodiment, transaction 3 can determine its conflict probability with each previous transaction based on the transaction data of each previous transaction, and based on the conflict probability, infer whether each transaction will be written to k1, thereby determining whether Enter the dormant state before the read operation to wait. For example, in the case where it is determined that the write probability of transaction 1 to k1 is greater than or equal to the predetermined threshold, and the write probability of transaction 2 to k1 is less than the predetermined threshold, the thread 3 records its status in the buffer 5 Wait for the submission or writing of transaction 1, and then enter the waiting process, that is, enter the dormant state.
In step S304, after the other executor completes the predetermined operation, the first executor is awakened through the other executor, so that the first executor continues to execute the first transaction.
In the above embodiment in which transaction 3 waits for the submission of transaction 2 after the execution is completed, thread 2 will query the second buffer after submitting transaction 2 to determine whether thread 3 is waiting for it. When thread 2 finds that the byte corresponding to transaction 3 in the second buffer is 3, thread 2 knows that thread 3 is currently dormant. Therefore, thread 2 wakes up thread 3 to make thread 3 can continue to execute transaction 3. After the thread 3 is awakened, the "3" in the second buffer can be modified to 0 to indicate that the thread 3 has been awakened. After the thread 3 is awakened, it is first in a waiting state. It will compete for the CPU with other idle threads. After the thread 3 preempts the CPU, it can begin to submit the transaction 3. Before submitting transaction 3, thread 3 can first check, and determine whether transaction 3 needs to be redone based on the record of the transaction submitted before. If redo is not required, thread 3 can submit transaction 3. A transaction window may also be set in the first node, and the maximum total number of transactions that can be executed simultaneously is controlled through the transaction window. 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 simultaneously. Therefore, after the thread 3 submits the transaction 3, it can also modify the transaction with the smallest number in the transaction window to 4.
In the embodiment where thread 3 waits for another thread (thread 11) to return to the variable read value, after thread 11 reads the value of variable k1, it wakes up execution according to the record of the request in the hardware Thread 3, and provide (for example, send) the read value to thread 3, so that thread 3 can also continue to execute the transaction based on the value of the variable k1 obtained from thread 11 after preempting the CPU 3. It can be understood that it is not necessary to send the read value to thread 3 through thread 11 here. For example, after thread 11 reads the value of k1, it can store the value of k1 in a predetermined address to execute Thread 3 can obtain the value of k1 at the predetermined address after being awakened.
In the embodiment in which thread 3 waits for the corresponding operation of transaction 1 based on the variable write table to read k1, thread 3 can be similar to the above-mentioned first embodiment by recording a signal to make thread 1 After performing the corresponding operation, wake up thread 3. For example, thread 3 can record that it is waiting for transaction 1 to be submitted in the buffer corresponding to the scene (shared or only corresponding to transaction 1). Therefore, after the thread 1 submits the transaction 1, it will query the buffer, and wake up the thread 3 based on the record of the thread 3, so that the thread 3 can continue to perform the read operation of k1 after preempting the CPU.
In the embodiment where the thread 3 waits for the corresponding operation of the transaction 2 based on the conflict probability to continue reading the variable k1, the thread 3 can be similar to the above-mentioned embodiment by recording a signal so that the thread 2 executes the corresponding operation. Wake up thread 3 after the operation. For example, thread 3 can record that it is waiting for transaction 2 to be submitted in a buffer corresponding to the scene (shared or only corresponding to transaction 2). Therefore, after the thread 2 submits the transaction 2, it will query the buffer and wake up the thread 3 based on the record of the thread 3, so that the thread 3 can continue to perform the read operation on k1 after preempting the CPU.
FIG. 4 shows a device 400 for simultaneously executing transactions in a blockchain according to an embodiment of the present specification. The device is deployed in a first node in the blockchain, and the first node is preset with a first node. The executive body, the first executive body is currently processing a first transaction, and the device includes:
The sleep unit 41 is configured to, after the first executor starts a first waiting process in the process of processing the first transaction, put the first executor to sleep, and the first waiting process is used to wait for other The executor completes the scheduled operation; and
The awakening unit 42 is configured to wake up the first executor through the other executor after the other executor completes the predetermined operation, so that the first executor continues to execute the first transaction.
In an embodiment, a second executor is preset in the first node, and the second executor is in a standby state before the first executor is put to sleep, and the device further includes an execution unit 43. It is configured to, after putting the first executor to sleep, start to execute the second transaction to be processed in the first node through the second executor, wherein the second executor is making the After the first executive body sleeps, it preempts the previous CPU corresponding to the first executive body.
In an embodiment, the dormant unit 41 is further configured to, after the first executor completes the first transaction, in a case where it is determined that the third transaction has not been submitted, make the first executor in The shared memory records that it is waiting for the submission of the third transaction, and then causes the first executive body to start the first waiting process, wherein the third transaction is the previous transaction of the first transaction according to a predetermined submission order.
In one embodiment, a third executor is preset in the first node, and the third transaction is executed by the third executor, and the wake-up unit 42 is further configured to execute in the third execution After the entity submits the third transaction, the first executor is awakened based on the record through the third executor.
In one embodiment, the first transaction includes a reading operation of the first variable, wherein the dormant unit 41 is further configured to request the reading of the first variable in the first executor After that, the first execution body is caused to start the first waiting process.
In one embodiment, a fourth executor is also preset in the first node, wherein the fourth executor performs a check after the first executor requests to read the first variable. In the reading of the first variable, the wake-up unit 42 is further configured to wake up the first execution through the fourth execution body after the fourth execution body reads the value of the first variable And provide the value of the first variable to the first executive body.
In one embodiment, the wake-up unit 42 is further configured to wake up the first executor after the first waiting process ends, so that the first executor continues to execute the CPU after preempting the CPU. The first transaction.
In one embodiment, the first transaction includes a read operation of the first variable, wherein the sleep unit 41 is further configured to: after the first executor executes the code to the read operation , Determine whether each transaction whose submission sequence is before the first transaction and not submitted is a conflict transaction that has performed the write operation to the first variable, and the each transaction includes a fourth transaction, and when determining the fourth transaction In the case of the conflicting transaction closest to the first transaction, the first executor is made to record in the shared memory that it is waiting for the submission of the fourth transaction, and then the first executor is caused to start the first waiting process.
In one embodiment, the awakening unit 42 is further configured to, after the thread that executes the fourth transaction submits the fourth transaction, wake up the thread based on the record of the first execution body in the shared memory through the thread. The first executive body.
In one embodiment, the first transaction includes a read operation of the first variable, wherein the sleep unit 41 is further configured to: after the first executor executes the code to the read operation , Infer 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, the each transaction includes the fifth transaction, and the fifth transaction is inferred to be the distance In the case of the most recent conflicting transaction of the first transaction, the first executor is made to record in the shared memory that it is waiting for the submission of the fifth transaction or waiting for the fifth transaction to perform the write operation, and then the first execution is made The body begins the first waiting process.
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 made to execute any of the above methods.
Another aspect of this specification provides a computing device, including a memory and a processor, characterized in that executable code is stored in the memory, and when the processor executes the executable code, any one of the above methods is implemented .
Through the solution of executing transactions at the same time according to the embodiment of this specification, the executive body enters the dormant state when it needs to wait during the execution of the transaction, and gives up CPU resources, and is awakened to continue executing the transaction after the waiting process is over, and the executive body is giving up the CPU After the resources, other executive bodies can preempt the CPU to process other transactions, thereby improving the utilization of the CPU and speeding up the overall speed of simultaneous execution of transactions.
It should be understood that the descriptions of "first", "second", etc. in this article are merely to distinguish similar concepts for 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 attached patent application. In some cases, the actions or steps described in the scope of the patent application may be performed in a different order from the embodiment 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, for clarity To illustrate the interchangeability of hardware and 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 herein 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 memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, hard disk, removable disk, CD -ROM, or any other form of storage medium known in the technical field.
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.
