阅读说明：本技术 一种基于线程逻辑时钟的事务内存的实现方法 (Method for realizing transactional memory based on thread logic clock ) 是由 王芳 冯丹 刘超杰 邹晓敏 于 2021-07-23 设计创作，主要内容包括：本发明公开了一种基于线程逻辑时钟的事务内存的实现方法,每个线程拥有一个自己的时间戳,时间戳包括线程ID和逻辑时钟,时间戳由时间戳管理器分配和回收；本发明还公开了基于线程逻辑时钟的事务内存的初始化、数据校验、事务提交的流程。本发明允许每个线程拥有自己的逻辑时钟,事务开始执行时读取自己线程的逻辑时钟,事务提交时将自己线程的逻辑时钟加1更新,由此避免了访问全局变量,消除了多个并发事务的读或更新操作所带来的缓存争用。(The invention discloses a method for realizing a transactional memory based on a thread logic clock, wherein each thread has a timestamp, the timestamp comprises a thread ID and a logic clock, and the timestamp is distributed and recovered by a timestamp manager; the invention also discloses the processes of initialization, data verification and transaction submission of the transaction memory based on the thread logic clock. The invention allows each thread to have its own logic clock, reads the logic clock of its own thread when the transaction starts to execute, and adds 1 to update the logic clock of its own thread when the transaction is submitted, thereby avoiding accessing global variables and eliminating cache contention caused by read or update operations of multiple concurrent transactions.)

1. A method for realizing a transaction memory based on a thread logic clock is characterized in that each thread has a timestamp, the timestamp comprises a thread ID and a logic clock, and the logic clock of the thread is read and recorded when the transaction is initialized; when the transaction commits, the logic clock of the thread is updated by adding 1.

2. The thread-based according to claim 1The method for realizing the transactional memory of the program logic clock is characterized in that the size of the timestamp is 64 bits, wherein the first n bits are used for storing the thread ID, the last 64-n bits are used for storing the logic clock, and n is log₂t, t is the number of threads currently running.

3. The method of claim 1, wherein the transactional memory implements a timestamp manager, and when a new thread is created, a timestamp is assigned to the new thread in the timestamp manager; when a thread is destroyed, the timestamp of the thread is reclaimed.

4. The method of claim 3, wherein the timestamp manager assigns a thread ID starting from 0 and corresponding to a logical clock of 0, and wherein the thread ID and the logical clock are incremented by 1.

5. The method of claim 3, wherein the timestamp manager uses a lock to guarantee concurrent assignment of timestamps.

6. The method of claim 3, wherein the recycled timestamp can be re-allocated for use.

7. The method of claim 1, wherein each raw data has its own timestamp, the timestamp of the raw data comprises a thread ID and a logic clock, and the raw data is data in the memory that is read or written by the transaction.

8. The method of claim 7, wherein when the transaction starts executing, the transaction initialization operation is to: the transaction creates an initial clock for the thread of the transaction, and the action range of the initial clock is only in the transaction; and the transaction reads the logic clock assignment of the thread of the transaction to the starting clock.

9. The method for implementing the transactional memory based on the thread timestamp as claimed in claim 8, wherein during the execution of the transaction, data check is required, comprising the following steps:

s 1: the transaction acquires a thread ID from a timestamp of original data, if the thread ID is not the thread ID of the transaction, an initial clock with a value of 0 is created for the thread ID, and the action range of the initial clock is only within the transaction.

s 2: if the logic clock of the original data is less than or equal to the starting clock corresponding to the thread ID, the transaction continues to be executed;

s 3: if the logic clock of the original data is larger than the starting clock corresponding to the thread ID, checking whether the time stamps of all data in the read set of the transaction are larger than or equal to the time stamps of the original data corresponding to the logic clock of the original data, if so, updating the starting clock corresponding to the thread ID by using the logic clock of the original data, and continuing executing the transaction; otherwise, the transaction is terminated and the transaction is redone.

10. The method of claim 7, wherein the transaction commit operation comprises the steps of:

s 1: checking whether the time stamps of all data in the read set of the transaction are greater than or equal to the time stamps of the corresponding original data;

s 2: if the value is larger than or equal to the original value, synchronizing the modified value of the original data in the write set of the transaction into the original data; adding 1 to a logic clock of the thread of the transaction to be used as a commit timestamp, and updating the timestamp of the thread of the transaction by using the commit timestamp, wherein the commit timestamp can be written into a timestamp of original data of the executed write operation; finally, releasing the lock obtained by the transaction and submitting the transaction;

s 3: if so, the transaction is terminated and the transaction is redone.

Technical Field

The invention belongs to the field of computer data storage, and particularly relates to a method for realizing a transactional memory based on a thread logic clock.

Background

Currently, most transactional memories are implemented based on timestamps: each transaction is executed by one thread, and each thread can execute multiple transactions, but can only execute one transaction at a time. Transactional memory requires maintaining a global logic clock, which is typically implemented using a global integer variable. The global logic clock distributes a time stamp for each thread, adds 1 to the current global logic clock value to assign the time stamp to the thread during each distribution, and updates the global logic clock by using the value added with 1. Transactional memory uses timestamps to ensure consistency of thread concurrency, which may be protected using locks in order to ensure correctness of multi-thread concurrency.

The transaction performs read or write operation on data in the memory, the data in the memory are original data, each original data has a timestamp of the original data, and the timestamp of the original data is a logic clock.

The transaction records the original data read by the transaction by using a read set (read-set), records the original data written by the transaction by using a write set (write-set), wherein the read set comprises the address and the time stamp of the original data, the write set comprises the address of the original data and the modified value of the original data, and the read set and the write set of the transaction are empty sets when the transaction is created.

Transactions are divided into two categories: one is an update transaction, which writes some data; the other is a read-only transaction, which does not write any data.

The transaction updating flow of the transactional memory based on the timestamp comprises the following steps:

in the first step, the transaction initialization operation: the current value of the global logic clock is obtained and recorded in a local variable named a start clock, wherein the value is represented by sc (start clock), the action range of sc is only in the affair, and sc is used for checking the consistency of data later.

Second, the read or write of data is started. It is necessary to verify that the original data being read is consistent when reading or writing the data, because other update transactions may be modifying the original data and if not, uncommitted modifications are read. The data verification process comprises the following steps: when the timestamp of the original data is less than or equal to sc and the lock corresponding to the original data is not acquired by other threads, the latest transaction for updating the original data is completed before the transaction starts, and no other transaction updates the transaction currently, the data is considered to be consistent at the moment, the data is checked to be passed, the transaction continues to execute, otherwise, the execution of the transaction is terminated and retried.

Thirdly, locking the original data for the write operation, and putting the modified value of the original data and the address of the original data into a write set; for a read operation, the address and timestamp of the original data are recorded in the read set.

Fourthly, transaction submitting operation, which comprises the following specific processes: the read set is checked first because the previously read value may be modified again during execution of the transaction. The method for checking the read set comprises the following steps: checking whether the time stamps of all the data in the read set are greater than or equal to the time stamps of the corresponding original data, if so, terminating the transaction and retrying; if the data is larger than or equal to the original data, the verification is successful, and the modification of the data in the write set is written back to the original data; adding 1 to the value of the global logic clock to obtain a commit timestamp (ct), updating the global logic clock by using the commit timestamp, and updating the timestamp of the original data subjected to the write operation to ct. Finally, the lock acquired by the transaction is released and the entire update transaction is completed.

The execution flow of the read-only transaction is simple, and comprises the following steps: the first step is the same as the update transaction, i.e. the current value sc of the global logic clock is obtained. Reading the original data and verifying the data, wherein the data verification flow is the same as that of the updating transaction, if the verification is passed, the address and the timestamp of the original data are recorded in the reading set, and the transaction is continuously executed; otherwise the transaction is terminated and retried. Read-only transactions do not require any commit because they do not make any modifications to the original data.

It can be seen from the execution flow that there are two places in the transactional memory based on the time stamp that the global logic clock needs to be operated on: (1) reading the value of the current global logic clock when the transaction is initialized; (2) when the transaction commits, 1 is added to the value of the global logic clock for updating. The first place is a read operation to the global logic clock, and the second place is an update operation to the global logic clock. When there are many concurrent transactions, the global logic clock is frequently read or updated by multiple transactions, which brings about a large amount of cache contention and further becomes a performance bottleneck of the whole system.

Disclosure of Invention

Aiming at the defects in the prior art, the invention aims to design a thread logic clock, and aims to solve the technical problem that the prior transactional memory uses a global logic clock to cause a large amount of cache contention in a multithreading environment.

In order to achieve the above object, the present invention provides a method for implementing a transactional memory based on a thread logic clock, wherein each thread has a timestamp thereof, the timestamp comprises a thread ID and a logic clock, and the logic clock of the thread thereof is read and recorded during a transaction initialization operation; when the transaction commits, the logic clock of the thread is updated by adding 1.

In the prior art, a current global logic clock needs to be read during transaction initialization operation, the global logic clock is realized by a global variable, 1 needs to be added for updating during transaction submission operation, and a plurality of concurrent transactions read or update the global logic clock, which brings a large amount of cache contention. The invention does not use the global logic clock any more, but allows each thread to have the own logic clock, reads the logic clock of the thread when the transaction is initialized, and adds 1 to update the logic clock of the thread when the transaction is submitted, thereby avoiding accessing the global variable and eliminating the cache contention caused by the read or update operation of a plurality of concurrent transactions.

Preferably, the timestamp is 64 bits in size, where the first n bits store the thread ID and the last 64-n bits are used to store the logical clock, and n is log₂t, t is the number of threads currently running.

Preferably, the transactional memory implements a timestamp manager, in which a timestamp is assigned to the new thread when the new thread is created; when a thread is destroyed, the timestamp of the thread is reclaimed.

The present invention no longer uses the thread ID provided by the system, but uses the timestamp manager to assign the thread ID and logical clock value to the thread. When the thread ID provided by the system is used, the thread ID is not recovered immediately after the thread operation is finished, but is recovered when the maximum value is reached, and along with the creation and destruction of the thread, a large number of thread IDs need to be maintained in the system, which increases the storage overhead. In the invention, the distribution and recovery of the thread ID are only called when the thread is created and destroyed, and a large amount of thread IDs do not need to be maintained in the system, so that the storage expense is not increased.

Preferably, the timestamp manager assigns a thread ID starting from 0, the corresponding logical clock is also 0, and both the thread ID and the logical clock are incremented by 1.

Preferably, the timestamp manager uses locks to guarantee concurrent distribution of timestamps.

Preferably, the recovered time stamp can be re-allocated for use

Preferably, each piece of original data has its own timestamp, the timestamp of the original data includes a thread ID and a logic clock, and the original data is data in a memory that is read or written by a transaction.

Preferably, when the transaction starts executing, the initialization operation is: the transaction establishes an initial clock for the thread of the transaction, and the action range of the initial clock is only in the transaction; the transaction reads the logic clock assignment of the own thread to the start clock.

Preferably, during the execution of the transaction, data check is required, which includes the following steps:

s 1: the transaction acquires a thread ID from a timestamp of original data, if the thread ID is not the thread ID of the transaction, an initial clock with a value of 0 is created for the thread ID, and the action range of the initial clock is only within the transaction.

s 2: if the logic clock of the original data is less than or equal to the starting clock corresponding to the thread ID, the transaction continues to be executed;

s 3: if the logic clock of the original data is larger than the starting clock corresponding to the thread ID, checking whether the time stamps of all data in the read set of the transaction are larger than or equal to the time stamps of the original data corresponding to the logic clock of the original data, if so, updating the starting clock corresponding to the thread ID by using the logic clock of the original data, and continuing executing the transaction; otherwise, the transaction is terminated and the transaction is redone.

Preferably, the commit operation of the transaction comprises the steps of:

s 1: checking whether the time stamps of all data in the read set of the transaction are greater than or equal to the time stamps of the corresponding original data;

s 2: if the value is larger than or equal to the original value, synchronizing the modified value of the original data in the write set of the transaction into the original data; adding 1 to a logic clock of the thread of the transaction to be used as a commit timestamp, and updating the timestamp of the thread of the transaction by using the commit timestamp, wherein the commit timestamp can be written into a timestamp of original data of the executed write operation; finally, releasing the lock obtained by the transaction and submitting the transaction;

s 3: if so, the transaction is terminated and the transaction is redone.

Compared with the prior art, the technical scheme of the invention allows each thread to have the own logic clock, and operates the logic clock of the thread when the transaction initialization operation and the transaction submission operation are carried out, thereby avoiding accessing the global variable and obtaining the beneficial effect of eliminating the cache contention caused by the read or update operation of a plurality of concurrent transactions.

Drawings

FIG. 1 is a block diagram of a thread timestamp provided by the present invention, where n is log₂t, t is the number of threads currently running;

FIG. 2 is a flow chart of a data verification operation provided by an embodiment of the present invention;

FIG. 3 is a flow diagram of a transaction commit operation provided by an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

Compared with the prior art, the execution process of the update transaction and the read-only transaction based on the thread logic clock is different only in the processes of transaction initialization operation, data verification and transaction submission operation, and the other operations are the same; the definition of the read set and write set of a transaction is also the same as in the prior art.

This embodiment is an example of an update transaction execution process based on thread logic clocks, which operates by reading data a and then modifying data b.

As in fig. 1, the time stamp is composed of a thread ID and a logical clock, denoted as (thread ID, logical clock). Because the thread ID of each thread is not the same, the timestamp of each thread is unique.

The state of the data before the transaction begins is that the timestamp of the data a is (1, 5), which indicates that a was modified by the thread 1 last time, and the clock value of the thread 1 at that time is 5; the timestamp of data b is (2, 4), indicating that b was last modified by thread 2 and the clock value for thread 2 at that time was 4. The transaction is executed by thread 1, with thread 1 having a timestamp of (1, 7).

Thread 1 performs a transaction initialization operation: creating an initial clock for the thread 1, wherein the action range of the initial clock is only inside the transaction; the logic clock 7 of the transaction read thread 1 is assigned to the start clock, and is recorded as sc (thread ID) which is the start clock, that is, sc (1) which is 7.

In the prior art, the current global logic clock needs to be read when the transaction is initialized. In the invention, the logic clock of the thread is read during the transaction initialization operation, thereby avoiding accessing the global variable and eliminating the cache contention caused by the read operation of a plurality of concurrent transactions.

Thread 1 reads data a: firstly, data verification is performed, as shown in fig. 2, the data verification process is as follows:

(1) the thread 1 acquires a thread ID of 1 from the time stamps (1, 5) of the data a, and the thread ID is the same as the thread ID of the transaction itself;

(2) comparing the logical clock of the data a with the starting clock of the thread 1, the logical clock 5 of the data a is smaller than the starting clock 7 of the thread 1, which shows that after the transaction starts, the data a is not modified by other transactions, the data passes the check, the data is consistent, and the transaction continues to execute.

Thread 1 reads the data of a, and puts the address and time stamp (1, 5) of data a into the read set.

Thread 1 modifies data b: firstly, data verification is performed, as shown in fig. 2, the data verification process is as follows:

(1) thread 1 obtains a thread ID of 2 from the timestamp (2, 4) of the data b, the thread ID is different from the thread ID of the transaction itself, the transaction creates a start clock with a value of 0 for thread 2, sc (2) is 0, and the scope of the start clock is only within the transaction.

In the invention, the transaction reads the logic clock of the thread of the transaction and assigns the logic clock to the starting clock of the thread of the transaction, and the starting clocks of other threads are set to be 0. This is because, if a transaction reads the logic clock of another thread and assigns the logic clock to the start clock of another thread, when multiple transactions are executed concurrently, the read operation of multiple transactions will incur a large amount of cache contention overhead, because according to the cache coherency protocol, after a thread reads the logic clock of another thread, a copy of the logic clock is added to its own cache, and if another thread modifies the logic clock, the copy in the thread needs to be synchronized, which is usually set to an invalid state. This synchronization operation incurs a significant amount of overhead as the number of concurrently executing transactions increases.

When an update transaction is committing, a commit timestamp is written to the timestamp of the data being written. Therefore, the history value of the logical clock of the thread is stored in the time stamp attribute of the data. The historical value is used because not all the time stamps of the data store the latest value of the logic clock, only a small amount of data store the latest value according to the execution flow of the thread logic clock, and most of the data store the old value of the logic clock, that is, the old value is smaller than the true logic clock. Using these older logic clocks to verify data consistency is entirely feasible because the clock value is always monotonically increasing, and if the data it accesses is modified by other update transactions after the transaction has started, the modified data must have a timestamp that is greater than any one of the old timestamps that were previously generated. The use of older logic clocks, which are smaller than the true logic clock, can be used to verify the consistency of the data. Therefore, in the invention, the transaction sets the starting clocks of other threads to be 0, which can be used for checking the data consistency and can also avoid a large amount of cache contention caused by reading the logic clocks of other threads by a plurality of transactions.

(2) Comparing the logical clock 4 of the data b with the starting clock of the thread 2, the logical clock 4 of the data b is larger than the starting clock 0 of the thread 2, the data check fails, but in fact, after the transaction starts, the data b is not modified by other transactions, and if the transaction is terminated, a higher transaction termination rate is brought. If the data accessed by the transaction is not modified by other threads after the transaction starts before the transaction is terminated, the starting clock of the thread 2 is modified to a larger value, so that the consistency of the data can still be ensured, meanwhile, the termination of the transaction is avoided, and the transaction can be continuously executed. The data accessed by the transaction after the transaction begins can be judged not to be modified by other threads by checking the read set. Because the written data can acquire the lock during access, the written data cannot be modified by other transactions, the data in the write set does not need to be checked, and only the read set needs to be checked.

(3) The time stamp of the data a in the reading set is (1, 5), the time stamp of the original data a is (1, 5), the two are consistent, and the verification is passed; updating the starting clock corresponding to the thread 2 by using the logic clock 4 of the original data b, namely, the sc (2) is 4, and the starting clock of the thread 2 is modified to a larger value; the transaction continues to execute.

Thread 1 locks original data b and puts the address of original data b and the modified value into the write set.

Thread 1 commits the transaction: referring to FIG. 3, the flow of committing a transaction is as follows:

(1) and checking whether the time stamps of all the data in the reading set are greater than or equal to the time stamps of the corresponding original data, wherein the time stamp of the data a in the reading set is (1, 5), the time stamp of the original data a is (1, 5), the time stamps are consistent, and the checking is passed.

(2) Writing the modification to the data b in the write set back to the original data b; the logical clock 7 of the thread 1 is added with 1 as a commit timestamp, the timestamp of the thread 1 is updated using the commit timestamp (1, 8), and the timestamp of the original data b is updated to the commit timestamp (1, 8). Finally, the lock acquired by the transaction is released and the entire update transaction is completed.

In the prior art, 1 is added to the global logic clock for updating when a transaction is submitted, and 1 is added to the logic clock of the thread of the transaction for updating when the transaction is submitted, so that cache contention caused by updating operations of a plurality of concurrent transactions is avoided.

It will be understood by those skilled in the art that the foregoing is only a preferred embodiment of the present invention, and is not intended to limit the invention, and that any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the scope of the present invention.