Consistency protocols for hardware transaction storage in shared memory using locked and unlocked non-volatile memory.

Abstract

This invention relates to a data processing system (100) and a data processing method. The data processing system (100) is used to execute hardware transactional memory (HTM) transactions. The data processing system (100) includes a byte-addressable non-volatile memory (101) for persistently storing data; and a processor (103) for performing atomic HTM write operations related to submitting the HTM transaction by writing an indication flag indicating successful submission of the HTM transaction to the non-volatile memory (101).

Description

Technical Field

[0001] This invention relates to a data processing system and method, and more particularly to storage access to the shared memory of the data processing system. Background Technology

[0002] In parallel programming computing environments, when parallel processor cores or programs share access to the same memory location, this access must be properly managed and synchronized. In some such environments, a transactional storage paradigm can be used to manage the synchronization of thread memory accesses. Under the transactional storage approach, threads can speculatively execute transactions without changing the contents of the shared memory location until the transaction is subsequently committed. If a conflict is detected between two transactions, one transaction may be aborted so that the other can be committed; in this case, the committed transaction may have changed the contents of the shared memory location.

[0003] More specifically, a traditional multiprocessor computer system includes multiple processing units and one or more address, data, and control buses. Coupled to these processing units is system memory, which represents the lowest level of volatile memory in the multiprocessor computer system and is typically accessible for reading and writing by all processing units. To reduce access latency to instructions and data residing in this system memory, each processing unit is typically further supported by a corresponding multilevel cache architecture, the lower levels of which may be shared by one or more processor cores.

[0004] Cache memory is typically used to temporarily buffer memory blocks that the processor may access, thereby speeding up processing by reducing access latency introduced by loading required data and instructions from system memory. In some multiprocessor systems, the cache architecture contains at least two tiers. The Level 1 (L1) or higher-level cache is usually a private cache associated with a specific processor core and cannot be accessed by other cores in the multiprocessor system. Typically, in response to a memory access instruction such as a load or store instruction, the processor core first accesses the directory of the higher-level cache. If the requested memory block is not found in the higher-level cache, the processor core searches for the requested memory block by accessing the lower-level cache (e.g., the Level 2 (L2) or Level 3 (L3) cache) or system memory. The lowest-level cache (e.g., the L3 cache) is typically shared by several processor cores.

[0005] In such systems, multiprocessor software concurrently accesses shared data structures through multiple software threads. When concurrently accessing shared data, it is typically necessary to prevent so-called "unconstrained races" or "conflicts." A conflict occurs when two memory accesses point to the same memory location, and at least one of them is a write, and the order in which these accesses occur cannot be guaranteed.

[0006] Multiprocessor software typically uses lock variables to coordinate concurrent reads and modifications of locations in memory in an ordered and conflict-free manner. A lock variable is a location in memory that can be read and set to a value atomically based on the read value. Read, modify, and write operations on lock variables are typically implemented through atomic read-modify-write instructions or through a sequence of instructions that provide the same effect as a single atomic read and modify instruction on the lock variable.

[0007] In this manner, a software thread that reads an initial "unlocked" value via an atomic read-modify-write instruction is considered to have "acquired" the lock and is the only software thread holding the lock until it is released. The thread holding the lock can safely update the shared memory location protected by the lock without conflicting with other threads, as other threads cannot acquire the lock until the current thread releases it. Once the shared location has been read and / or modified, the thread holding the lock releases it (e.g., by writing the lock variable to an "unlocked" value) to allow other threads to access the shared location in memory.

[0008] Locks have several well-known drawbacks when used to coordinate access to shared data by competing threads. These include: first, deadlocks can occur when a given thread holds more than one lock and prevents other threads from processing; and second, acquiring locks can be costly when there are no conflicts in accessing shared data and locks are not strictly necessary.

[0009] To overcome these limitations, the concept of transactional storage can be adopted. In transactional storage, a set of load and / or store instructions is considered a "transaction." A transaction succeeds when a component's load and store operations can occur atomically without conflicting with another thread. If a conflict occurs with another thread, the transaction fails and can then be retried. If the transaction fails again, the software may fall back to using locks to ensure ordered access to shared data.

[0010] To support transactional storage and resolve conflicts, the underlying hardware tracks the storage locations involved in a transaction during execution—the transaction footprint. If a conflict is found in the transaction footprint, the transaction will abort and may restart. The use of transactional storage reduces the likelihood of deadlocks caused by a single thread holding multiple locks, because typically, no locks are held simultaneously (the transaction simply attempts to perform one or more storage accesses, restarting if a conflict occurs). Furthermore, the overhead of acquiring locks is generally avoided.

[0011] Transactional memory is understood in the form of hardware transactional memory (HTM) and software transactional memory (STM). Hardware transactional memory (HTM) systems may require modifications to the processor, cache, and bus protocols to support transactions. Software transactional memory (STM) provides the semantics of transactional memory within a software runtime library or programming language. Future generations of multi-core processors will implement hardware transactional memory (HTM), as described in document "...". As described in the "Architecture Instruction Set Extension Programming Reference". Summary of the Invention

[0012] The present invention aims to provide a more complete data processing system and method.

[0013] This objective is achieved through the spirit of the independent claims. Specific implementations are described in the dependent claims, specification, and drawings. This invention is based on the following concept: atomically adding a persistent indicator in an HTM commit, recording each HTM write, and flushing each HTM write after the commit, to allow hardware transactional memory (HTM) to maintain consistency and persistence in non-volatile memory in the event of system failure.

[0014] According to a first aspect of the present invention, a data processing system is used to execute hardware transactional memory (HTM) transactions, the data processing system comprising:

[0015] Byte-addressed non-volatile memory used for persistent data storage;

[0016] The processor is configured to perform atomic HTM write operations related to the submission of the HTM transaction by writing an indication identifier to non-volatile memory indicating that the HTM transaction has been successfully committed.

[0017] According to the first implementation of the first aspect, the processor is coupled to a cache memory through multiple cache lines, the cache memory being used by the processor to cache data using a cache coherency protocol.

[0018] According to the second implementation of the first aspect, the data processing system is also used to record the write operation associated with the HTM transaction in the non-volatile memory before the HTM transaction is successfully committed.

[0019] According to the third implementation of the first aspect, the data processing system is further configured to record the write operations associated with the HTM transaction in the non-volatile memory by transparently updating the log of the write operations associated with the HTM transaction to the non-volatile memory before the HTM transaction is successfully committed.

[0020] According to the fourth possible implementation of the first aspect, the data processing system further includes a recovery unit for: if the log of the write operation associated with the HTM transaction exists in non-volatile memory and the HTM transaction is in a recording state, redoing the log of the data processing system when the data processing system restarts, wherein the indicator is set to indicate that the HTM transaction is in a recording state; and if the redoing event is completed, setting the HTM transaction to an unrecorded state, wherein the indicator is de-set to indicate that the HTM transaction is in an unrecorded state.

[0021] According to the fifth possible implementation of the first aspect, the data processing system is also used to flush the data written by the HTM operation from the cache memory to the non-volatile memory after the HTM transaction is successfully committed.

[0022] According to the sixth implementation of the first aspect, the data processing system is also used to set the HTM transaction to an unrecorded state after the HTM transaction is successfully committed, wherein the HTM transaction is set to an unrecorded state by canceling the setting of the indicator.

[0023] According to the seventh implementation of the first aspect, the data processing system is also used to flush the data written by the HTM operation from the cache memory to the non-volatile memory without aborting the HTM transaction.

[0024] According to the eighth implementation of the first aspect, the indication identifier indicates that the successful commit of the HTM transaction includes an HTM transaction identifier, wherein the HTM transaction identifier is a commit record.

[0025] According to the second aspect, a data processing method for performing hardware transactional memory (HTM) transactions includes the following steps: performing an atomic HTM write operation related to the submission of the HTM transaction by writing an indication flag indicating that the HTM transaction has been successfully committed to a non-volatile memory.

[0026] The first implementation of the second aspect includes the following steps: before the HTM transaction is successfully committed, the write operation associated with the HTM transaction is executed in the non-volatile memory by transparently flushing the log of the write operation associated with the HTM transaction to the non-volatile memory.

[0027] The second implementation of the second aspect includes the following steps: if the log of the write operation associated with the HTM transaction exists in non-volatile memory and the HTM transaction is in a recording state, redo the log of the data processing system, wherein the indicator is set to indicate that the HTM transaction is in a recording state; and if the redo event is completed, set the HTM transaction to an unrecorded state, wherein the indicator is de-set to indicate that the HTM transaction is in an unrecorded state.

[0028] The third implementation of the second aspect includes the following steps: after the HTM transaction is successfully committed, the data written by the HTM operation is flushed from the cache memory to the non-volatile memory.

[0029] The fourth implementation of the second aspect includes the following steps: after the HTM transaction is successfully committed, the HTM transaction is set to an unrecorded state by unsetting the indicator flag.

[0030] The fifth implementation of the second aspect includes the following steps: flushing the data written by the HTM operation from the cache memory to the non-volatile memory without aborting the HTM transaction.

[0031] According to a third aspect of the present invention, there is computer program code for executing, when executed on a computer, a data processing method as described in the second aspect or its implementation thereof. Attached Figure Description

[0032] Specific embodiments of the present invention will be described in conjunction with the following drawings, wherein:

[0033] Figure 1 A schematic diagram of a data processing system provided in one embodiment is shown;

[0034] Figure 2 A schematic diagram of a data processing method provided in one embodiment is shown;

[0035] Figure 3 A state diagram of a data processing system provided in one embodiment is shown;

[0036] Figure 4 The illustration shows different aspects of a data processing system provided in one embodiment and provides schematic diagrams with implementation details about each step. Detailed Implementation

[0037] The following detailed description is taken in conjunction with the accompanying drawings, which are an integral part of the description and illustrate specific aspects in which the invention can be practiced. It is understood that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the invention. Therefore, the following detailed description is not intended to be limiting, and the scope of the invention is defined by the appended claims.

[0038] It is understood that the content relating to the described method also applies to the device or system corresponding to the execution of the method, and vice versa. For example, if a specific method step is described, the corresponding device or system may include units for executing the described method step, even if such units are not detailed or illustrated in the figures. Furthermore, it should be understood that, unless otherwise specifically indicated, features of the various exemplary aspects described herein can be combined with each other.

[0039] Figure 1 A schematic diagram of a data processing system 100 according to one embodiment is shown. The data processing system 100 is used to execute hardware transactional memory (HTM) transactions. The data processing system (100) includes byte-addressable non-volatile memory (101) for persistent storage of data and a processor (103). The processor 103 is used to perform atomic HTM write operations related to committing the HTM transaction by writing an indication flag indicating successful HTM transaction commit to the non-volatile memory. In one embodiment, the indication flag may be a non-volatile bit in the HTM transaction commit.

[0040] Nonvolatile memory (NVM or NVRAM) is a byte-addressable memory that is durable, meaning that data in it persists even during power failures. In this embodiment, log entries (including successful commit indicators) and application data are maintained in the NVM.

[0041] In one embodiment, the HTM transaction needs to write log records and flush the log records and application data to the NVM without aborting itself or other running transactions. This requires a special type of flush instruction that is transparent to the HTM system, which we call transparent flush (TF). Existing architectures from major vendors use flush instructions that do not remove flushed addresses from the cache, thus enabling the transparent flush (TF) mechanism. For example, in an x86 microarchitecture, a thread running an HTM transaction using TSX blocks writes log records to the cache and then uses the CLWB instruction to flush the log records to the log area in the NVM.

[0042] After the machine restarts, the recovery process reads the commit indicator from NVM. If the commit indicator is set to true, it means that the transaction was successful but still logged. The process then reads the log record and writes it to the application data area accordingly.

[0043] According to one embodiment, the indicator can be accessed via... Figure 4 This is achieved through commit records. A successful commit means that the transaction writes are atomically visible to all processing units in the system.

[0044] In one embodiment, the processor 103 is coupled to a buffer memory 105 via multiple cache lines 106, the buffer memory 105 being used by the processor 103 to cache data via a cache coherence protocol.

[0045] In one embodiment, the data processing system 100 is further configured to create a log record in the log recording area of ​​the non-volatile memory 101, and record the write operations of cached data associated with the HTM transaction in the log recording area. The data structure of the log record can be referenced from... Figure 4 For example, it includes Commit Record, Self_id, Size, and<DATA、ADDR> A tuple. The Commit Record is an indicator of a continuously successful commit. The Self id is a unique identifier for the event.<DATA、ADDR> Tuple: A log record containing the data and address of a single cached line written by a transaction. Size is the number of log records in a transaction.

[0046] In one embodiment, the data processing system 100 is configured to: record the write operations of the cached data associated with the HTM transaction in the recording area by transparently refreshing the log of write operations of the cached data associated with the HTM transaction to the non-volatile memory 101 before the HTM transaction is committed. The transparent refresh is invisible to both the cache memory 105 and the HTM system.

[0047] In one embodiment, the data processing system 100 further includes a recovery unit 107, configured to: redo the log when restarting the data processing system 100 if the commit record is set to true and the log record data associated with the HTM operation exists in the non-volatile memory 101. Redoing the log means rewriting the application data area based on the log record area that is still in the recording state, which may not have been flushed to the non-volatile memory 101 before the system failure (e.g., power failure).

[0048] In one embodiment, the data processing system 100 is further configured to, after submitting the HTM transaction, refresh the modified application data associated with the HTM operation from the cache to the application data area in the non-volatile memory 101.

[0049] In one embodiment, the data processing system 100 is further configured to transparently refresh the modified application data associated with the HTM operation from the cache to the cache before the HTM transaction is committed. Figure 4 The log recording area in the non-volatile memory 101 shown, and its flushing to the specified location after the HTM transaction is committed. Figure 4 The application data area in the non-volatile memory 101 shown is used without interrupting the HTM transaction.

[0050] In one embodiment, the indication flag indicating a successful commit of the HTM transaction includes an HTM transaction commit record. The commit record can be a Boolean variable, whose value of true indicates that the transaction has been successfully committed. As long as the commit record is in the set state, writes to the transaction are in the recorded state and will be resumed upon restart.

[0051] Figure 2 This is a flowchart of the main stages of a persistent HTM transaction provided in one embodiment.

[0052] This diagram illustrates all the stages of a successful persistent HTM transaction:

[0053] 1. Start an HTM transaction.

[0054] 2. Write application data into the cache and record it in the log record of NVM's logging area.

[0055] 3. Successfully commit the transaction, and at the same time, set the indicator in the commit record of the NVM log area to true.

[0056] 4. If there is no failure, refresh the modified application data from the cache to the application data area in NVM.

[0057] 5. If a failure occurs and the indicator is true, the modified application data is copied from the logging area in NVM to the application data in the application data area of ​​NVM upon restart. Alternatively, if the indicator is false, the transaction is ignored.

[0058] 6. Set the indicator flag in the commit record of the NVM log area to false.

[0059] In the following text, further embodiments and implementations of the data processing system 100 and the data processing method 200 are described in more detail using the following symbols and definitions.

[0060] Let the HTM transaction executed by, for example, processor 103 be denoted as T. k A restart of the data processing system 100 brings the data to a consistent state, eliminates the effects of uncommitted transactions, and applies the loss effect of committed transactions (restart). If a transaction is successfully committed, it is finalized, and all writes in the cache are flushed to the application data area in NVM 101, and the commit record is set to false. If a subsequent restart occurs, the transaction will be ignored. If α is a storage address in cache 105, a TF(α) called transparent flush will write α to the non-volatile memory in either the application data area or the log area, but it will not invalidate it or affect cache consistency in any way.

[0061] In one embodiment, the state of a data item x (addressable word) in NVM 101 written by an HTM transaction T is determined by... Figure 3 The following three characteristics are defined as follows: (1) "Private" / "Shared": "Private" means that x is only in the L1 cache of one thread and is not visible to other threads. When x is "Shared", cache consistency makes its new value visible. (2) "Persistent" / "Volatile": "Persistent" means that the last write to x was in NVM 101; otherwise, the new value of x is "volatile" in cache 105 and will be lost in the event of a power failure. (3) "Logged" / "Cleared": If x is "Logged", a restart will recover x from the non-volatile log. If x is "Cleared", a restart will not affect x because its logging has been completed or its transaction has not been successfully committed.

[0062] Figure 3 This application illustrates a data processing system (e.g., Figure 1The data processing system 100 shown illustrates a state machine for a single write in an HTM transaction. According to one embodiment, this mechanism enables the atomic conversion of <“private”, "clear”> to <“shared”, "logged”> and allows conversion from <“volatile”> to <“persistent”> without interrupting the HTM transaction for concurrent reads of the data item. Generally, the "logged" characteristic applies to the entire HTM transaction. Converting all writes of a single transaction from "clear" to "logged" requires a single persistent write. In an HTM commit according to an embodiment of this application, all writes are exposed by the HTM and logged simultaneously. In one embodiment, each write generates a persistent log record, but the write is not logged until a successful commit is made, and in a sense, is not replayable by a restarted process. Figure 4 It is a detailed flowchart of the behavior at different stages.

[0063] When HTM transaction Tk writes to variable x, x is in the L1 cache of processor 103 (e.g., Figure 1 The transaction is marked as "private" in cache 105 (shown), meaning it is private within the L1 cache 105 of processor 103. Since it exists only in cache 105, the transaction is "volatile," and since it has not been committed, it is "cleared," meaning it is not "logged." Not being logged means that x will not be written to by a restarted process. In the event of a data processing system 100 shutdown or power failure, the "volatile" and "private" x value will be discarded, and the system will revert to its previous "shared" and "persistent" values.

[0064] In one embodiment, the state of x changes twice during an HTM commit. It becomes "shared," meaning it is visible and also "logged." In one embodiment, the two changes occur atomically upon a successful commit. After a successful commit, HTM transparently refreshes the new value of x to NVM 101 and clears x. Clearing refers to first setting the commit record (indicator) to false and then unsetting the log indicator in a second step. This log indicator is used to verify that an address can only be logged by one transaction in the system, and that a restarted process writes the last value written to that address to that address at most once via an HTM transaction. This log indicator is one embodiment of this patent and not part of the claims. If system 100 fails and restarts while x is "logged," processor 103 writes the commit value of x from the log record of x to the application data area in the NVM and then clears x.

[0065] In one embodiment, the logging in this NVM 101 is not a typical sequential log. Instead, it only saves log records for transactions that are currently running or committed by HTM and whose log records have not yet been reclaimed.

[0066] As those skilled in the art will understand, if L1 cache 105 is non-volatile, HTM will be persistent when no further modifications are made. A restart event can abort a running transaction, and committed HTM transactions in cache 105 will become persistent and require no logging. However, due to hardware limitations, such as the rapid wear and slow writes of the NVM 101, the cache architecture will remain in volatile SRAM for the foreseeable future.

[0067] like Figure 3 As shown, in one embodiment, the transaction T k Successful submission will automatically mark this indicator as T. k The commit record is set to true, such as Figure 4 As shown. In one embodiment, this can be achieved by processor 103 using the "tx_end_log(Tk)" instruction. This instruction performs an HTM commit and sets T. k Submission history. Figure 4 The layout of the persistent footprint of transaction Tk in an NVM101 provided in one embodiment is illustrated schematically. It includes indicators for which Tk can be used as a persistent footprint. k The commit record is "logged". The instruction "tx_end_log(Tk)" writes the commit record to this NVM 101, and at the same time sets T... k The write status is set to "recorded".

[0068] In one embodiment, processor 103 is used to flush modified data from cache 105 to NVM 101 via running transactions without aborting those transactions. During the completion of transaction T, for example, after the instruction "tx_end_log(T)", i.e., after HTM commit, T flushes application data from cache 105 to the application data region in NVM 103 without aborting ongoing concurrent transactions reading this value. In one embodiment, these flushes do not create any consistency requirements and do not invalidate the data in cache 105. This operation is referred to herein as transparent flush (TF) because it has no impact on the caching architecture and the HTM subsystem.

[0069] In one embodiment, the processor 103 may provide an API for HTM transactions, including the "tx_start()" and "tx_end()" functions for initiating and committing HTM transactions. Non-persistent HTM implementations include these functions. In persistent HTM, "tx_start()" refers to initiating an HTM transaction, even in the volatile case, while "tx_end()" is expanded to flush the transaction log record from the cache to the logging area in the NVM, followed by an HTM commit and indicator flag setting performed concurrently with an API call such as the "tx_end_log(T)" instruction, subsequently flushing the application data itself from the cache to the application data area in the NVM. In one embodiment, machine storage instructions may be replaced by a preprocessor with functions such as "tx_write(address, data, size)". The tx_write() function creates a log record in the NVM's logging area, for example, by a non-transient write, and writes the application data to the application data cache. In one embodiment, appearing in Figure 4 In the HTM transaction shown, the log record and size field are flushed as part of the transaction, but not as part of the commit instruction. However, multiple writes to the same cached line can be written to the same log record. Therefore, in one embodiment, the log record is flushed only once before commit to prevent multiple flushes of the same data.

[0070] In one embodiment, processor 103 is used to employ a best-effort strategy when processor 103 does not provide progress guarantees. Therefore, in conventional volatile HTM, after a certain number of aborts, transactions must undergo global locking and commit. However, with NVM, global locking is insufficient because temporary writes may have already polluted memory. Therefore, in one embodiment, an undo log entry is created for each volatile HTM write. In an alternative embodiment, a full redo log is created before writing the first value to NVM 101. The first embodiment reduces reads after the write overhead.

[0071] As mentioned above, utilizing volatile caches (such as Figure 1 The cache 105 shown, and the committed HTM transactions that store all writes in the cache, in one embodiment, the processor 103 is used to record the writes, thereby allowing recovery in the event of a restart if the writes are still volatile after the HTM commit. In one embodiment, the processor 103 is used to ensure that all writes to the log reach the NVM 101 before the HTM commit, while all transaction writes are retained in the cache 105. In one embodiment, the processor 103 is used to flush the log to the NVM 101 without aborting the executing transactions, i.e., a transparent flush, as described above.

[0072] In one embodiment, processor 103 is configured such that the log can provide the last committed value of variable x for each log entry to the restart process. In one embodiment, processor 103 is used to append a version to x. In one embodiment, processor 103 is used to verify that x was logged only once in system 100. If x is allowed to appear in multiple logs, the latest version of x should be retained in the log.

[0073] In one embodiment, each address is allowed to appear in at most one log. To avoid instances of the same address in multiple logs, in one embodiment, a volatile log tag array is added, where each storage address is mapped to a tag. In one embodiment, when a transaction is about to write to x, it also marks x as recorded. In one embodiment, other transactions are not allowed to write to x until it is flushed. The reason for using tags or indicators in one embodiment is to prevent writing to a variable that has already been written to another transaction but has not yet been flushed, so it is still recorded. All other conflicts can be handled directly by HTM. In one embodiment, the tag or indicator array can be volatile, such that, in the event of a restart, the recorded addresses are unique, and the restart and recovery process does not create any new log records. After a restart, according to one embodiment, a new and empty tag or indicator array can be allocated.

[0074] In one embodiment, the writing of a tag or indicator is part of a transaction, i.e., if transaction T k When x is written, it also marks x, and during a commit, the write and the marking will work simultaneously because they are both transaction writes; upon abort, they are both canceled. In one embodiment, as long as the marking is set, the value appearing in T cannot be changed. k The value of x in the log. Therefore, after flushing x from the cache to the application data area in NVM 101 and setting the commit record to false, the flag can be unset. It is important to emphasize that transaction load instructions can ignore the flag and execute at full speed, which is a key advantage of HTM according to this application, since reading transactions is processed at hardware speed.

[0075] Figure 4 A persistent structure for logging transaction T is shown in one embodiment. In one embodiment, T has the following... Figure 4 The boolean commit record shown is set in tx_end_log. In one embodiment, the commit record is written by the HTM commit microcode, so the commit record should reside on the fastest available non-volatile memory. In one embodiment, the transaction also has a unique ID stored in self_id. In one embodiment, the transaction has a set of log records. In one embodiment, as... Figure 4As shown, each log record consists of the data in the modified cache line and the address of that line in system memory. In one embodiment, the maximum total size of the data is equal to the size of the L1 cache 105, which is the maximum size of the data written and recorded. In one embodiment, the size field is the number of log records in the transaction log. In one embodiment, assuming the size is zero, the transaction is not recorded, and the record and size can be combined. However, for clarity, the two are treated separately here. In one embodiment, T's Figure 4 All log recording areas are flushed to NVM 101 only once, so if a cached row is written multiple times in the same transaction, the data for that row is only flushed to the record once before commit T.

[0076] In one embodiment, the DATA.ADDR field (the address and corresponding data of the application data in the NVM) in the log record allows a restarted process or a completion to determine which address and application data to write or flush. In one embodiment, the address is in a separate array and not attached to the data to avoid cache fragmentation. In one embodiment, the mapping of the address itself is used to acquire and release write instructions and completion markers.

[0077] While specific features or aspects of the invention may have been disclosed only in conjunction with one of several embodiments or examples, such features or aspects may be combined with one or more features or aspects in other embodiments or examples, as long as it is necessary or advantageous for any given or particular application. Furthermore, to a certain extent, the terms “comprising,” “having,” “having,” or other variations of these words are used in the detailed description or claims, and such terms, like the term “including,” are intended to mean encompassing. Similarly, the terms “exemplary,” “for example,” are used only as examples and not as best or preferred. The terms “coupled” and “connected” and their derivatives may be used. It should be understood that these terms may be used to indicate that two elements cooperate or interact with each other, whether they are in direct physical contact or electrical contact, or whether they are not in direct contact with each other.

[0078] While specific aspects have been illustrated and described herein, those skilled in the art will understand that various alternatives and / or equivalent embodiments may be implemented without departing from the scope of the invention regarding the specific aspects shown and described. This application is intended to cover any modifications or alterations to the specific aspects discussed herein.

[0079] Although the elements in the foregoing claims are listed in a particular order using corresponding labels, these elements are not necessarily limited to being implemented in that particular order unless the formulation of the claims otherwise implies a particular order for implementing parts or all of these elements.

[0080] Based on the above description, many substitutions, modifications, and variations will be apparent to those skilled in the art. Of course, those skilled in the art will readily recognize that numerous other applications of the invention exist besides those described herein. Although the invention has been described with reference to one or more specific embodiments, those skilled in the art will recognize that many changes can be made to the invention without departing from its scope. Therefore, it should be understood that the invention can be practiced in ways other than those specifically described herein, as long as it remains within the scope of the appended claims and their equivalents.

Claims

1. A data processing system, characterized in that, The data processing system is used to execute hardware transaction storage (HTM) transactions, and includes: Byte-addressed non-volatile memory used for persistent data storage; The processor is used to submit an HTM transaction, write application data related to the HTM transaction into a cache memory, and record the application data in the log recording area of ​​the non-volatile memory. If the HTM transaction is successfully submitted, the processor further sets an indicator flag in the non-volatile memory, the indicator flag being used to indicate that the HTM transaction has been successfully submitted. The data processing system further includes a recovery unit for: If a write operation associated with the HTM transaction exists in the log recording area of ​​non-volatile memory, and the HTM transaction is in a logged state, the application data area is rewritten according to the log recording area when the data processing system restarts, wherein the indicator is set to indicate that the HTM transaction is in a logged state, and if the rewriting of the HTM transaction is completed, the HTM transaction is set to an unlogged state, wherein the indicator is de-set to indicate that the HTM transaction is in an unlogged state.

2. The system according to claim 1, characterized in that, The processor is also used for: The application data is refreshed from the cache memory to the application data area of ​​the non-volatile memory.

3. The system according to claim 2, characterized in that, The processor is also used for: After the application data is refreshed from the cache memory to the application data area of ​​the non-volatile memory, the indicator is de-set in the non-volatile memory.

4. The system according to any one of claims 1 to 3, characterized in that, The processor is also used for: Upon restart, confirm whether the indicator is set in the non-volatile memory. If so, rewrite the application data recorded in the log recording area to the application data area of ​​the non-volatile memory, and remove the indicator from the non-volatile memory.

5. The system according to any one of claims 1 to 3, characterized in that, The processor is also used for: Upon restart, check whether the indicator is set in the non-volatile memory; if not, ignore the HTM transaction.

6. The system according to any one of claims 1 to 3, characterized in that, The indicator is a Boolean variable. A true value indicates that the HTM transaction has been successfully committed, while a false value indicates that the HTM transaction has not been successfully committed.

7. A data processing method for executing hardware transaction storage (HTM) transactions, characterized in that, The data processing method includes the following steps: Submit the HTM transaction, write the application data related to the HTM transaction into the cache memory, and record the application data in the log recording area of ​​the non-volatile memory; If the HTM transaction is successfully committed, an indicator flag is further set in the non-volatile memory to indicate that the HTM transaction has been successfully committed. If a write operation associated with the HTM transaction exists in the log recording area of ​​non-volatile memory, and the HTM transaction is in a logged state, the application data area is rewritten according to the log recording area when the data processing system restarts, wherein the indicator is set to indicate that the HTM transaction is in a logged state, and if the rewriting of the HTM transaction is completed, the HTM transaction is set to an unlogged state, wherein the indicator is de-set to indicate that the HTM transaction is in an unlogged state.

8. The method according to claim 7, characterized in that, Also includes: The application data is refreshed from the cache memory to the application data area of ​​the non-volatile memory.

9. The method according to claim 8, characterized in that, Also includes: After the application data is refreshed from the cache memory to the application data area of ​​the non-volatile memory, the indicator is de-set in the non-volatile memory.

10. The method according to any one of claims 7 to 9, characterized in that, Also includes: Upon restart, confirm whether the indicator is set in the non-volatile memory. If so, rewrite the application data recorded in the log recording area to the application data area of ​​the non-volatile memory, and remove the indicator from the non-volatile memory.

11. The method according to any one of claims 7 to 9, characterized in that, Also includes: Upon restart, check whether the indicator is set in the non-volatile memory; if not, ignore the HTM transaction.

12. The method according to any one of claims 7 to 9, characterized in that, The indicator is a Boolean variable. A true value indicates that the HTM transaction has been successfully committed, while a false value indicates that the HTM transaction has not been successfully committed.

13. A computer program product, characterized in that, For use in executing the data processing method of any one of claims 7 to 12 on a computer.

Images