US20050262301A1 - Method and apparatus for delaying interfering accesses from other threads during transactional program execution - Google Patents

Method and apparatus for delaying interfering accesses from other threads during transactional program execution Download PDF

Info

Publication number
US20050262301A1
US20050262301A1 US11189591 US18959105A US2005262301A1 US 20050262301 A1 US20050262301 A1 US 20050262301A1 US 11189591 US11189591 US 11189591 US 18959105 A US18959105 A US 18959105A US 2005262301 A1 US2005262301 A1 US 2005262301A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
cache
transactional
execution
line
during
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11189591
Inventor
Quinn Jacobson
Marc Tremblay
Shailender Chaudhry
Original Assignee
Jacobson Quinn A
Marc Tremblay
Shailender Chaudhry
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0862Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with prefetch
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815Cache consistency protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0842Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/3004Arrangements for executing specific machine instructions to perform operations on memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/30076Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/30087Synchronisation or serialisation instructions
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098Register arrangements
    • G06F9/30105Register structure
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098Register arrangements
    • G06F9/30105Register structure
    • G06F9/30116Shadow registers, e.g. coupled registers, not forming part of the register space
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3824Operand accessing
    • G06F9/3834Maintaining memory consistency
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836Instruction issuing, e.g. dynamic instruction scheduling, out of order instruction execution
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836Instruction issuing, e.g. dynamic instruction scheduling, out of order instruction execution
    • G06F9/3842Speculative instruction execution
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836Instruction issuing, e.g. dynamic instruction scheduling, out of order instruction execution
    • G06F9/3851Instruction issuing, e.g. dynamic instruction scheduling, out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836Instruction issuing, e.g. dynamic instruction scheduling, out of order instruction execution
    • G06F9/3857Result writeback, i.e. updating the architectural state
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3861Recovery, e.g. branch miss-prediction, exception handling
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/466Transaction processing
    • G06F9/467Transactional memory

Abstract

One embodiment of the present invention provides a system that facilitates delaying interfering memory accesses from other threads during transactional execution. During transactional execution of a block of instructions, the system receives a request from another thread (or processor) to perform a memory access involving a cache line. If performing the memory access on the cache line will interfere with the transactional execution and if it is possible to delay the memory access, the system delays the memory access and stores copy-back information for the cache line to enable the cache line to be copied back to the requesting thread. At a later time, when the memory access will no longer interfere with the transactional execution, the system performs the memory access and copies the cache line back to the requesting thread.

Description

    RELATED APPLICATION
  • [0001]
    This application hereby claims priority under 35 U.S.C. §119 to U.S. Provisional Patent Application No. 60/447,128, filed on 13 Feb. 2003, entitled “Transactional Memory,” by inventors Shailender Chaudhry, Marc Tremblay and Quinn Jacobson (Attorney Docket No. SUN-P9322PSP).
  • BACKGROUND
  • [0002]
    1. Field of the Invention
  • [0003]
    The present invention relates to techniques for improving the performance of computer systems. More specifically, the present invention relates to a method and an apparatus for delaying memory accesses from other threads that interfere with on-going transactional program execution.
  • [0004]
    2. Related Art
  • [0005]
    Computer system designers are presently developing mechanisms to support multi-threading within the latest generation of Chip-Multiprocessors (CMPs) as well as more traditional Shared Memory Multiprocessors (SMPs). With proper hardware support, multi-threading can dramatically increase the performance of numerous applications. However, as microprocessor performance continues to increase, the time spent synchronizing between threads (processes) is becoming a large fraction of overall execution time. In fact, as multi-threaded applications begin to use even more threads, this synchronization overhead becomes the dominant factor in limiting application performance.
  • [0006]
    From a programmer's perspective, synchronization is generally accomplished through the use locks. A lock is typically acquired before a thread enters a critical section of code, and is released after the thread exits the critical section. If another thread wants to enter the same critical section, it must acquire the same lock. If it is unable to acquire the lock, because a preceding thread has grabbed the lock, the thread must wait until the preceding thread releases the lock. (Note that a lock can be implemented in a number of ways, such as through atomic operations or semaphores.)
  • [0007]
    Unfortunately, the process of acquiring a lock and the process of releasing a lock are very time-consuming in modern microprocessors. They involve atomic operations, which typically flush the load buffer and store buffer, and can consequently require hundreds, if not thousands, of processor cycles to complete.
  • [0008]
    Moreover, as multi-threaded applications use more threads, more locks are required. For example, if multiple threads need to access a shared data structure, it is impractical for performance reasons to use a single lock for the entire data structure. Instead, it is preferable to use multiple fine-grained locks to lock small portions of the data structure. This allows multiple threads to operate on different portions of the data structure in parallel. However, it also requires a single thread to acquire and release multiple locks in order to access different portions of the data structure.
  • [0009]
    In some cases, locks are used when they are not required. For example, many applications make use of “thread-safe” library routines that use locks to ensure that they are “thread-safe” for multi-threaded applications. Unfortunately, the overhead involved in acquiring and releasing these locks is still incurred, even when the thread-safe library routines are called by a single-threaded application.
  • [0010]
    Applications typically use locks to ensure mutual exclusion within critical sections of code. However, in many cases threads will not interfere with each other, even if they are allowed to execute a critical section simultaneously. In these cases, mutual exclusion is used to prevent the unlikely case in which threads actually interfere with each other. Consequently, in these cases, the overhead involved in acquiring and releasing locks is largely wasted.
  • [0011]
    Hence, what is needed is a method and an apparatus that reduces the overhead involved in manipulating locks when accessing critical sections.
  • [0012]
    One technique to reduce the overhead involved in manipulating locks is to “transactionally” execute a critical section, wherein changes made during the transactional execution are not committed to the architectural state of the processor until the transactional execution successfully completes. This technique is described in related U.S. patent application Ser. No. 10/637,168, entitled, “Selectively Monitoring Loads to Support Transactional Program Execution,” by inventors Marc Tremblay, Quinn A. Jacobson and Shailender Chaudhry, filed on 8 Aug. 2003 (Attorney Docket No. SUN-P9327-MEG).
  • [0013]
    During transactional execution, load and store operations are modified so that they mark cache lines that are accessed during the transactional execution. This allows the computer system to determine if an interfering data access occurs during the transactional execution. If so, the transactional execution fails, and results of the transactional execution are not committed to the architectural state of the processor. One the other hand, if the transactional execution successfully executes a block of instructions, results of the transactional execution are atomically committed to the architectural state of the processor.
  • [0014]
    Unfortunately, this commit operation does not happen instantaneously. During the commit operation, stores that took place during transactional execution must somehow be committed to the architectural state of the processor. Note that there can potentially be a large number of stores, so committing these stores can take a significant amount of time. While the stores are being committed, an interfering data access from another thread can potentially occur. However, failing the transactional execution to deal with this type of interfering data access during the commit operation is not a viable option, because doing so can leave the processor in an inconsistent state, with only a portion of the transactional updates committed.
  • [0015]
    Hence, what is needed is a method and an apparatus for preventing accesses from other threads from interfering with transactional program execution, and in particular that prevents accesses from other threads from interfering with a commit operation that takes place at the end of transactional program execution.
  • SUMMARY
  • [0016]
    One embodiment of the present invention provides a system that facilitates delaying interfering memory accesses from other threads during transactional execution. During transactional execution of a block of instructions, the system receives a request from another thread (or processor) to perform a memory access involving a cache line. If performing the memory access on the cache line will interfere with the transactional execution and if it is possible to delay the memory access, the system delays the memory access and stores copy-back information for the cache line to enable the cache line to be copied back to the requesting thread. At a later time, when the memory access will no longer interfere with the transactional execution, the system performs the memory access and copies the cache line back to the requesting thread.
  • [0017]
    In a variation on this embodiment, it is possible to delay an interfering memory access if a commit operation is in the process of committing updates made during the transactional execution to the architectural state of the processor, and if the memory access is directed to a cache line for which a last update made during the transactional execution has not yet been committed to the architectural state of the processor.
  • [0018]
    In a further variation, a cache line associated with a delayed memory access is copied back to the requesting thread after the last update to the cache line during the transactional execution is committed to the architectural state of the processor.
  • [0019]
    In a variation on this embodiment, the cache line associated with a delayed memory access is copied back to the requesting thread after all updates that took place during the transactional execution are committed to the architectural state of the processor.
  • [0020]
    In a variation on this embodiment, it is possible to delay an interfering memory access prior to the commit operation. In this case, if the transactional execution fails prior to the commit operation, the system copies back cache lines for any interfering memory accesses that have been delayed during the transactional execution, wherein the data that is copied back is original cache line data, which has not been modified during the transactional execution.
  • [0021]
    In a variation on this embodiment, if the memory access will interfere with the transactional execution and if it is not possible to delay the memory access, the system discards changes made during the transactional execution. The system also allows the memory access to complete and attempts to re-execute the block of instructions.
  • [0022]
    In a further variation, discarding changes made during transactional execution involves: discarding register file changes made during the transactional execution; clearing load marks from cache lines; draining store buffer entries generated during the transactional execution; and clearing store marks from cache lines.
  • [0023]
    In a variation on this embodiment, an interfering memory access can include: a store by another thread to a cache line that has been load-marked by the thread; and a load or a store by another thread to a cache line that has been store-marked by the thread.
  • [0024]
    In a variation on this embodiment, commencing transactional execution involves: saving processor registers; configuring the processor to load-mark cache lines during loads that take place during transactional execution; configuring the processor to store-mark cache lines during stores that take place during transactional execution; and configuring the processor to continually monitor data references from other threads to detect interfering data references.
  • [0025]
    In a variation on this embodiment, if transactional execution completes without encountering an interfering memory access from another thread, the system commits changes made during the transactional execution to the architectural state of the processor, and resumes normal non-transactional execution of the program past the block of instructions.
  • [0026]
    In a further variation, committing changes made during transactional execution involves: clearing load marks from cache lines; committing register file changes made during transactional execution; and committing store buffer entries generated during the transactional execution to memory. Note that if a store buffer entry contains a last update made to a cache line made during the transactional execution, committing the store buffer entry can involve unmarking the corresponding cache line.
  • [0027]
    In a variation on this embodiment, the request to perform the memory access can include a request-to-own (RTO) signal or a request-to-share (RTS) signal.
  • BRIEF DESCRIPTION OF THE FIGURES
  • [0028]
    FIG. 1 illustrates a computer system in accordance with an embodiment of the present invention.
  • [0029]
    FIG. 2 illustrates how a critical section is executed in accordance with an embodiment of the present invention.
  • [0030]
    FIG. 3 presents a flow chart illustrating the transactional execution process in accordance with an embodiment of the present invention.
  • [0031]
    FIG. 4 presents a flow chart illustrating a start transactional execution (STE) operation in accordance with an embodiment of the present invention.
  • [0032]
    FIG. 5 presents a flow chart illustrating how load-marking is performed during transactional execution in accordance with an embodiment of the present invention.
  • [0033]
    FIG. 6 presents a flow chart illustrating how store-marking is performed during transactional execution in accordance with an embodiment of the present invention.
  • [0034]
    FIG. 7 presents a flow chart illustrating how a commit operation is performed in accordance with an embodiment of the present invention.
  • [0035]
    FIG. 8 presents a flow chart illustrating how changes are discarded after transactional execution completes unsuccessfully in accordance with an embodiment of the present invention.
  • [0036]
    FIG. 9A presents a flow chart illustrating how monitored and unmonitored load instructions are generated in accordance with an embodiment of the present invention.
  • [0037]
    FIG. 9B presents a flow chart illustrating how monitored and unmonitored load instructions are executed in accordance with an embodiment of the present invention.
  • [0038]
    FIG. 10A presents a flow chart illustrating how monitored and unmonitored store instructions are generated in accordance with an embodiment of the present invention.
  • [0039]
    FIG. 10B presents a flow chart illustrating how monitored and unmonitored store instructions are executed in accordance with an embodiment of the present invention.
  • [0040]
    FIG. 11 presents a timeline illustrating transactional program execution in accordance with an embodiment of the present invention.
  • [0041]
    FIG. 12 illustrates various items of state information associated with an L2 cache line in accordance with an embodiment of the present invention.
  • [0042]
    FIG. 13 presents a flow chart illustrating how interfering accesses are delayed during transactional program execution in accordance with an embodiment of the present invention.
  • DETAILED DESCRIPTION
  • [0043]
    The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
  • [0044]
    The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs or digital video discs), and computer instruction signals embodied in a transmission medium (with or without a carrier wave upon which the signals are modulated). For example, the transmission medium may include a communications network, such as the Internet.
  • [0000]
    Computer System
  • [0045]
    FIG. 1 illustrates a computer system 100 in accordance with an embodiment of the present invention. Computer system 100 can generally include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a personal organizer, a device controller, and a computational engine within an appliance. As is illustrated in FIG. 1, computer system 100 includes processors 101 and level 2 (L2) cache 120, which is coupled to main memory (not shown). Processor 102 is similar in structure to processor 101, so only processor 101 is described below.
  • [0046]
    Processor 101 has two register files 103 and 104, one of which is an “active register file” and the other of which is a backup “shadow register file.” In one embodiment of the present invention, processor 101 provides a flash copy operation that instantly copies all of the values from register file 103 into register file 104. This facilitates a rapid register checkpointing operation to support transactional execution.
  • [0047]
    Processor 101 also includes one or more functional units, such as adder 107 and multiplier 108. These functional units are used in performing computational operations involving operands retrieved from register files 103 or 104. As in a conventional processor, load and store operations pass through load buffer 111 and store buffer 112.
  • [0048]
    Processor 101 additionally includes a level one (L1) data cache 115, which stores data items that are likely to be used by processor 101. Note that each line in L1 data cache 115 includes a “load-marking bit,” which indicates that a data value from the line has been loaded during transactional execution. This load-marking bit is used to determine whether any interfering memory references take place during transactional execution as is described below with reference to FIGS. 3-8. Processor 101 also includes an L1 instruction cache (not shown).
  • [0049]
    Note that load-marking does not necessarily have to take place in L1 data cache 115. In general load-marking can take place at any level cache, such as L2 cache 120, or even in an independent structure. However, for performance reasons, the load-marking will likely take place at the cache level that is as close to the processor as possible, which in this case is L1 data cache 115. Otherwise, loads would have to go to L2 cache 120 even on an L1 hit.
  • [0050]
    L2 cache 120 operates in concert with L1 data cache 115 (and a corresponding L1 instruction cache) in processor 101, and with L1 data cache 117 (and a corresponding L1 instruction cache) in processor 102. Note that L2 cache 120 is associated with a coherency mechanism 122, such as the reverse directory structure described in U.S. patent application Ser. No. 10/186,118, entitled, “Method and Apparatus for Facilitating Speculative Loads in a Multiprocessor System,” filed on Jun. 26, 2002, by inventors Shailender Chaudhry and Marc Tremblay (Publication No. US-2002-0199066-A1). This coherency mechanism 122 maintains “copyback information” 121 for each cache line. This copyback information 121 facilitates sending a cache line from L2 cache 120 to a requesting processor in cases where a cache line must be sent to another processor.
  • [0051]
    Each line in L2 cache 120 includes a “store-marking bit,” which indicates that a data value has been stored to the line during transactional execution. This store-marking bit is used to determine whether any interfering memory references take place during transactional execution as is described below with reference to FIGS. 3-8. Note that store-marking does not necessarily have to take place in L2 cache 120.
  • [0052]
    Ideally, the store-marking takes place in the cache level closest to the processor where cache lines are coherent. For write-through L1 data caches, writes are automatically propagated to L2 cache 120. However, if an L1 data cache is a write-back cache, we perform store-marking in the L1 data cache. (Note that the cache coherence protocol ensures that any other processor that subsequently modifies the same cache line will retrieve the cache line from the L1 cache, and will hence become aware of the store-mark.)
  • [0000]
    Executing a Critical Section
  • [0053]
    FIG. 2 illustrates how a critical section is executed in accordance with an embodiment of the present invention. As is illustrated in the left-hand side of FIG. 2, a thread that executes a critical section typically acquires a lock associated with the critical section before entering the critical section. If the lock has been acquired by another thread, the thread may have to wait until the other thread releases the lock. Upon leaving the critical section, the thread releases the lock. (Note that the terms “thread” and “process” are used interchangeably throughout this specification.)
  • [0054]
    A lock can be associated with a shared data structure. For example, before accessing a shared data structure, a thread can acquire a lock on the shared data structure. The thread can then execute a critical section of code that accesses the shared data structure. After the thread is finished accessing the shared data structure, the thread releases the lock.
  • [0055]
    In contrast, in the present invention, the thread does not acquire a lock, but instead executes a start transactional execution (STE) instruction before entering the critical section. If the critical section is successfully completed without interference from other threads, the thread performs a commit operation, to commit changes made during transactional execution. This sequence of events is described in more detail below with reference to FIGS. 3-8.
  • [0056]
    Note that in one embodiment of the present invention a compiler replaces lock-acquiring instructions with STE instructions, and also replaces corresponding lock releasing instructions with commit instructions. (Note that there may not be a one-to-one correspondence between replaced instructions. For example, a single lock acquisition operation comprised of multiple instructions may be replaced by a single STE instruction.) The above discussion presumes that the processor's instruction set has been augmented to include an STE instruction and a commit instruction. These instructions are described in more detail below with reference to FIGS. 3-9.
  • [0000]
    Transactional Execution Process
  • [0057]
    FIG. 3 presents a flow chart illustrating how transactional execution takes place in accordance with an embodiment of the present invention. A thread first executes an STE instruction prior to entering of a critical section of code (step 302). Next, the system transactionally executes code within the critical section, without committing results of the transactional execution (step 304).
  • [0058]
    During this transactional execution, the system continually monitors data references made by other threads, and determines if an interfering data access (or other type of failure) takes place during transactional execution. If not, the system atomically commits all changes made during transactional execution (step 308) and then resumes normal non-transactional execution of the program past the critical section (step 310).
  • [0059]
    On the other hand, if an interfering data access is detected, the system discards changes made during the transactional execution (step 312), and attempts to re-execute the critical section (step 314).
  • [0060]
    In one embodiment of the present invention, the system attempts the transactionally re-execute the critical section zero, one, two or more times. If these attempts are not successful, the system executes an alternative block of code in normal execution mode. This alternative code may perform additional attempts to perform the transaction and will likely have the ability to reverts back to the conventional technique of acquiring a lock on the critical section before entering the critical section, and then releasing the lock after leaving the critical section.
  • [0061]
    Note that an interfering data access can include a store by another thread to a cache line that has been load-marked by the thread. It can also include a load or a store by another thread to a cache line that has been store-marked by the thread.
  • [0062]
    Also note that circuitry to detect interfering data accesses can be easily implemented by making minor modifications to conventional cache coherence circuitry. This conventional cache coherence circuitry presently generates signals indicating whether a given cache line has been accessed by another processor. Hence, these signals can be used to determine whether an interfering data access has taken place.
  • [0000]
    Starting Transactional Execution
  • [0063]
    FIG. 4 presents a flow chart illustrating a start transactional execution (STE) operation in accordance with an embodiment of the present invention. This flow chart illustrates what takes place during step 302 of the flow chart in FIG. 3. The system starts by checkpointing the register file (step 402). This can involve performing a flash copy operation from register file 103 to register file 104 (see FIG. 1). In addition to checkpointing register values, this flash copy can also checkpoint various state registers associated with the currently executing thread. In general, the flash copy operation checkpoints enough state to be able to restart the corresponding thread.
  • [0064]
    At the same time the register file is checkpointed, the STE operation also causes store buffer 112 to become “gated” (step 404). This allows existing entries in store buffer to propagate to the memory sub-system, but prevents new store buffer entries generated during transactional execution from doing so.
  • [0065]
    The system then starts transactional execution (step 406), which involves load-marking and store-marking cache lines, if necessary, as well as monitoring data references in order to detect interfering references.
  • [0000]
    Load-Marking Process
  • [0066]
    FIG. 5 presents a flow chart illustrating how load-marking is performed during transactional execution in accordance with an embodiment of the present invention. During transactional execution of a critical section, the system performs a load operation. In performing this load operation if the load operation has been identified as a load operation that needs to be load-marked, system first attempts to load a data item from L1 data cache 115 (step 502). If the load causes a cache hit, the system “load-marks” the corresponding cache line in L1 data cache 115 (step 506). This involves setting the load-marking bit for the cache line. Otherwise, if the load causes a cache miss, the system retrieves the cache line from further levels of the memory hierarchy (step 508), and proceeds to step 506 to load-mark the cache line in L1 data cache 115.
  • [0000]
    Store-Marking Process
  • [0067]
    FIG. 6 presents a flow chart illustrating how store-marking is performed during transactional execution in accordance with an embodiment of the present invention. During transactional execution of a critical section, the system performs a store operation. If this store operation has been identified as a store operation that needs to be store-marked, the system first prefetches a corresponding cache line for exclusive use (step 602). Note that this prefetch operation will do nothing if the line is already located in cache and is already in an exclusive use state.
  • [0068]
    Since in this example L1 data cache 115 is a write-through cache, the store operation propagates through L1 data cache 115 to L2 cache 120. The system then attempts to lock the cache line corresponding to the store operation in L2 data cache 115 (step 604). If the corresponding line is in L2 cache 120 (cache hit), the system “store-marks” the corresponding cache line in L2 cache 120 (step 610). This involves setting the store-marking bit for the cache line. Otherwise, if the corresponding line is not in L2 cache 120 (cache miss), the system retrieves the cache line from further levels of the memory hierarchy (step 608) and then proceeds to step 610 to store-mark the cache line in L2 cache 120.
  • [0069]
    Next, after the cache line is store-marked in step 610, the system enters the store data into an entry of the store buffer 112 (step 612). Note that this store data will remain in store buffer 112 until a subsequent commit operation takes place, or until changes made during the transactional execution are discarded.
  • [0070]
    Note that a cache line that is store marked by a given thread can be read by other threads. Note that this may cause the given thread to fail while the other threads continue.
  • [0000]
    Commit Operation
  • [0071]
    FIG. 7 presents a flow chart illustrating how a commit operation is performed after transactional execution completes successfully in accordance with an embodiment of the present invention. This flow chart illustrates what takes place during step 308 of the flow chart in FIG. 3.
  • [0072]
    The system starts by treating store-marked cache lines as though they are locked (step 702). This means other threads that request a store-marked line must wait until the line is no longer locked before they can access the line. This is similar to how lines are locked in conventional caches.
  • [0073]
    Next, the system clears load-marks from L1 data cache 115 (step 704).
  • [0074]
    The system then commits entries from store buffer 112 for stores that are identified as needing to be marked, which were generated during the transactional execution, into the memory hierarchy (step 706). As each entry is committed, a corresponding line in L2 cache 120 is unlocked.
  • [0075]
    The system also commits register file changes (step 708). For example, this can involve functionally performing a flash copy between register file 103 and register file 104 in the system illustrated in FIG. 1.
  • [0000]
    Discarding Changes
  • [0076]
    FIG. 8 presents a flow chart illustrating how changes are discarded after transactional execution completes unsuccessfully in accordance with an embodiment of the present invention. This flow chart illustrates what takes place during step 312 of the flow chart in FIG. 3. The system first discards register file changes made during the transactional execution (step 802). This can involve either clearing or simply ignoring register file changes made during transactional execution. This is easy to accomplish because the old register values were checkpointed prior to commencing transactional execution. The system also clears load-marks from cache lines in L1 data cache 115 (step 804), and drains store buffer entries generated during transactional execution without committing them to the memory hierarchy (step 806). At the same time, the system unmarks corresponding L2 cache lines. Finally, in one embodiment of the present invention, the system branches to a target location specified by the STE instruction (step 808). The code at this target location attempts to re-execute the critical section as is described above with reference to step 314 of FIG. 1.
  • [0000]
    Monitored Load Instructions
  • [0077]
    FIG. 9A presents a flow chart illustrating how monitored and unmonitored load instructions are generated in accordance with an embodiment of the present invention. This process takes place when a program is being generated to support transactional execution. For example, in one embodiment of the present invention, a compiler or virtual machine automatically generates native code to support transactional execution. In another embodiment, a programmer manually generates code to support transactional execution.
  • [0078]
    The system first determines whether a given load operation within a block of instructions to be transactionally executed needs to be monitored (step 902). In one embodiment of the present invention, the system determines whether a load operation needs to be monitored by determining whether the load operation is directed to a heap. Note that a heap contains data that can potentially be accessed by other threads. Hence, loads from the heap need to be monitored to detect interference. In contrast, loads from outside the heap, (for example, from the local stack) are not directed to data that is shared by other threads, and hence do not need to be monitored to detect interference.
  • [0079]
    One embodiment of the present invention determines whether a load operation needs to be monitored at the programming-language level, by examining a data structure associated with the load operation to determine whether the data structure is a “protected” data structure for which loads need to be monitored, or an “unprotected” data structure for which loads do not need to be monitored.
  • [0080]
    In yet another embodiment, the system allows a programmer to determine whether a load operation needs to be monitored.
  • [0081]
    If the system determines that a given load operation needs to be monitored, the system generates a “monitored load” instruction (step 904). Otherwise, the system generates an “unmonitored load” instruction (step 906).
  • [0082]
    There are a number of different ways to differentiate a monitored load instruction from an unmonitored load instruction. (1) The system can use the op code to differentiate a monitored load instruction from an unmonitored load instruction. (2) Alternatively, the system can use the address of the load instruction to differentiate between the two types of instructions. For example, loads directed to a certain range of addresses can be monitored load instructions, whereas loads directed to other address can be unmonitored load instructions.
  • [0083]
    Also note that an unmonitored load instruction can either indicate that no other thread can possibly interfere with the load operation, or it can indicate that interference is possible, but it is not a reason to fail. (Note that in some situations, interfering accesses to shared data can be tolerated.)
  • [0084]
    FIG. 9B presents a flow chart illustrating how monitored and unmonitored load instructions are executed in accordance with an embodiment of the present invention. The system first determines whether the load instruction is a monitored load instruction or an unmonitored load instruction (step 910). This can be accomplished by looking at the op code of the load instruction, or alternatively, looking at the address for the load instruction. Note that the address can be examined by comparing the address against boundary registers, or possibly examining a translation lookaside buffer (TLB) entry fro the address to determine if the address falls within a monitored range of addresses.
  • [0085]
    If the load instruction is a monitored load instruction, the system performs the corresponding load operation and load marks the associated cache line (step 914). Otherwise, if the load instruction is an unmonitored load instruction, the system performs the load operation without load-marking the cache line (step 916).
  • [0086]
    In a variant of the embodiment of the present invention, the system does not allow an unmarked load operation from the current thread cause other threads to fail transactional execution. This can be accomplished by propagating additional information during the coherency transactions associated with the load operation to ensure that the load operation does not cause another thread to fail.
  • [0000]
    Monitored Store Instructions
  • [0087]
    FIG. 10A presents a flow chart illustrating how monitored and unmonitored store instructions are generated in accordance with an embodiment of the present invention. As was described above for load operations, this process can take place when a compiler or virtual machine automatically generates native code to support transactional execution, or when a programmer manually generates code to support transactional execution.
  • [0088]
    The system first determines whether a store operation within a block of instructions to be transactionally executed needs to be monitored (step 1002). This determination can be made in the based on the same factors as for load instructions.
  • [0089]
    If the system determines that a store operation needs to be monitored, the system generates a “monitored store” instruction (step 1004). Otherwise, the system generates an “unmonitored store” instruction (step 1006).
  • [0090]
    Note that monitored store instructions can be differentiated from unmonitored store instructions in the same way that monitored load instructions can be differentiated from unmonitored load instructions, for example the system can use different op codes or different address ranges.
  • [0091]
    FIG. 10B presents a flow chart illustrating how monitored and unmonitored store instructions are executed in accordance with an embodiment of the present invention. The system first determines whether the store instruction is a monitored store instruction or an unmonitored store instruction (step 1010). This can be accomplished by looking at the op code for the store instruction, or alternatively, looking at the address for the store instruction. If the store instruction is a monitored store instruction, the system performs the corresponding store operation to a gated store buffer, or in another way so that it can be later undone, and store marks the associated cache line (step 1014). Otherwise, if the store instruction is an unmonitored store instruction, the system performs the store operation without store-marking the cache line (step 1016).
  • [0092]
    Note that a store-marked cache line can indicate one or more of the following: (1) loads from other threads to the cache line should be monitored; (2) stores from other threads to the cache line should be monitored; or (3) stores to the cache line should be buffered until the transactional execution completes.
  • [0093]
    In a variant of the embodiment of the present invention, the system does not allow an unmarked store operation from the current thread cause another thread to fail transactional execution. This can be accomplished by propagating additional information during coherency transactions associated with the store operation to ensure that the store operation does not cause another thread to fail.
  • [0000]
    Delaying Interfering Accesses
  • [0094]
    FIG. 11 presents a timeline illustrating transactional program execution in accordance with an embodiment of the present invention. At the beginning of transactional program execution, a checkpoint operation 1102 takes place. This enables the system to return to the checkpoint if a failure subsequently occurs during transactional execution. During transactional execution, a number of load and store operations are performed, which cause corresponding cache lines to be marked. (Note that only the store operations are illustrated in FIG. 11.) At the end of transactional execution, a commit operation takes place, which commits changes made during the speculative execution to the architectural state of the processor. In one embodiment of the present invention, this involves committing entries from a store buffer into the L2 cache. Finally, after all changes made during the transactional execution are committed to the architectural state of the processor, the commit operation is complete, and normal, non-speculative program execution resumes.
  • [0095]
    Note that during a problem window 1104 results of the transactional execution are being committed to the architectural state of the processor. During this problem window, interfering accesses from other threads can potentially occur. However, failing transactional execution within problem window 1104 to deal with an interfering access can cause problems. In particular, if the commit operation is only partially complete, it is possible to leave the processor in an inconsistent state, with only a portion of the transactional updates committed. One way to solve this problem is to delay interfering data accesses until the commit operation completes. This delaying technique is described in more detail below with reference to FIGS. 12-13. (Note that an interfering access from another process can include a cache-coherence signal, such as a request-to-own (RTO) signal or a request-to-share (RTS) signal.)
  • [0000]
    State Information
  • [0096]
    FIG. 12 illustrates various items of state information associated with an L2 cache line in accordance with an embodiment of the present invention. Much of this state information is standard for cache lines in a cache-coherent computer system. In particular, the cache line illustrated in FIG. 12 includes data 1218 and address tag field 1201, as well as state bits associated with cache coherence operations, including valid bit 1204, dirty bit 1206 and owned bit 1208.
  • [0097]
    In addition to this standard state information, the system maintains a store-mark bit 1210, which indicates that the cache line was written to during transactional execution, and that at least one corresponding store buffer entry is waiting to be committed to the cache line. The system also maintains a locked bit 1212, which indicates that the cache line is to remain locked in cache during the commit operation until the corresponding store buffer entry (or entries) are committed to the cache line. (Note that it may be possible to combine store-mark bit 1210 and locked bit 1212 into a single same bit.) In one embodiment of the present invention, the system also maintains a thread ID 1211, which indicates which thread has locked (or has store-marked) the cache line.
  • [0098]
    The system can also maintain copy-back information for the cache line, including a “to be copied back bit” 1214, which indicates whether the cache line has to be copied back to another thread. It also includes a copy back list 1216, which identifies where the cache line has to be copied back to. In one embodiment of the present invention, copy-back list 1216 is a one-hot bit vector, wherein each bit indicates whether the cache line has to be copied back to a specific thread (or processor).
  • [0099]
    Note that there are many alternative ways to encode the state information illustrated in FIG. 12. For example, in one embodiment of the present invention, the system encodes the state information illustrated in FIG. 12 using a more dense encoding into fewer bits.
  • [0000]
    Process of Delaying an Interfering Access
  • [0100]
    FIG. 13 presents a flow chart illustrating how interfering accesses are delayed during transactional program execution in accordance with an embodiment of the present invention. During operation, the system obtains ownership of a cache line in L2 cache 120 (step 1302). Shared ownership is sufficient for cache lines that are only read while exclusive ownership is necessary for caches lines stored to. Next, during subsequent transactional program execution, the system load-marks cache lines in L1 cache and store marks cache lines in L2 cache as described above (step 1304).
  • [0101]
    If an interfering access from another process is encountered during transactional execution, the system fails the transaction as described above and possibly gives up ownership of the cache line (step 1306). The system then returns to step 1304 and attempts to repeat the failed transactional execution.
  • [0102]
    In an alternative embodiment of the present invention (indicated by the dashed line), instead of failing the transaction, the system delays the interfering access and stores copy back information to enable the interfering access to complete at a later time (step 1308). Note that if the interfering access is a store to a load-marked cache line, the interfering access can complete as soon as the commit operation begins, without having to wait for stores to be committed to the architectural state of the processor. Otherwise, in the case of a load or a store to a store-marked cache line, the system has to wait until after the last update to the cache line during the transactional execution is committed to the architectural state of the processor before completing the interfering access. (Note that a load from a load-marked cache line does not interfere with transactional program execution.)
  • [0103]
    In this alternative embodiment, if transactional execution for some reason fails, the system copies back cache lines for any interfering accesses that have been delayed during transactional execution (step 1305). In doing so, the system copies back original cache line data, which has not been modified during the transactional execution. Next, the system returns to step 1304 and attempts to repeat the filed transactional execution.
  • [0104]
    After transactional execution completes, the system performs a commit operation (step 1309). During this commit operation, stores that took place during transactional execution are drained from the store buffer to the L2 cache (which represents the architectural state of the processor). If an interfering access from another process is encountered during the commit operation, the system delays the interfering access and stores copy back information to enable the interfering access to complete at a later time (step 1310). (While delaying this access, the system can possibly acknowledge ownership of the cache line as part of a cache coherence protocol and can delay performing a copy-back operation, or equivalent operation that gives up ownership, for the cache line.) The system then returns to step 1309 to complete the commit operation.
  • [0105]
    After all stores are all committed, the system can complete all delayed accesses and can perform copy-back operations as necessary (step 1312). The system can also give up ownership of the corresponding cache lines if necessary. Next, the system then returns to normal non-transactional execution (step 1314).
  • [0106]
    Note that it is not necessary to wait until all stores are committed before performing the copy-back operations, or equivalent operations that gives up ownership,. In one embodiment of the present invention, a given cache line is copied back to requesting threads after the last update to the given cache line that took place during the transactional execution is committed to the architectural state of the processor.
  • [0107]
    The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.

Claims (23)

  1. 1-25. (canceled)
  2. 26. An apparatus that facilitates delaying memory accesses directed to cache lines associated with transactional execution, comprising:
    a transactional execution mechanism configured to commence transactional execution of a block of instructions within a thread executing on a processor; and
    a request processing mechanism configured to receive a request from a requesting thread to perform a memory access involving a cache line;
    wherein if performing the memory access on the cache line will interfere with the transactional execution and if it is possible to delay the memory access, the request processing mechanism is configured to perform the memory access at a later time when the memory access will not interfere with the transaction.
  3. 27. The apparatus of claim 26, wherein while performing the memory access at a later time when the memory access will not interfere with the transaction, the request processing mechanism is configured to:
    store copy-back information for the cache line to enable the cache line to be copied back to the requesting thread, and to
    perform the memory access and copy the cache line back to the requesting thread at a later time when the memory access will not interfere with the transactional execution.
  4. 28. The apparatus of claim 26, wherein performing the memory access involves copying the cache line back to the requesting thread.
  5. 29. The apparatus of claim 26, wherein it is possible to delay an interfering memory access if a commit operation is in the process of committing updates made during the transactional execution to the architectural state of the processor, and if the memory access is directed to a cache line for which a last update made during the transactional execution has not yet been committed to the architectural state of the processor.
  6. 30. The apparatus of claim 29, wherein the request processing mechanism is configured to copy back a cache line associated with a delayed memory access to the requesting thread after the last update to the cache line during the transactional execution is committed to the architectural state of the processor.
  7. 31. The apparatus of claim 29, wherein the request processing mechanism is configured to copy back a cache line associated with a delayed memory access to the requesting thread after all updates that took place during the transactional execution are committed to the architectural state of the processor.
  8. 32. The apparatus of claim 29, wherein it is possible to delay an interfering memory access prior to the commit operation; and
    wherein if the transactional execution fails prior to the commit operation, the request processing mechanism is configured to copy back cache lines for any interfering memory accesses that have been delayed during the transactional execution, wherein the data that is copied back is original cache line data, which has not been modified during the transactional execution.
  9. 33. The apparatus of claim 26, wherein if the memory access will interfere with the transactional execution and if it is not possible to delay the memory access, the transactional execution mechanism is configured to:
    discard changes made during the transactional execution;
    allow the memory access to complete; and to
    attempt to re-execute the block of instructions.
  10. 34. The apparatus of claim 33, wherein while discarding changes made during the transactional execution, the transactional execution mechanism is configured to:
    discard register file changes made during the transactional execution;
    clear load marks from cache lines;
    drain store buffer entries generated during the transactional execution; and to
    clear store marks from cache lines.
  11. 35. The apparatus of claim 26, wherein an interfering memory access can include:
    a store by another thread to a cache line that has been load-marked by the thread; and
    a load or a store by another thread to a cache line that has been store-marked by the thread.
  12. 36. The apparatus of claim 26, wherein while commencing transactional execution, the transactional execution mechanism is configured to:
    save processor registers;
    configure the processor to load-mark cache lines during loads that take place during transactional execution;
    configure the processor to store-mark cache lines during stores that take place during transactional execution; and to
    configure the processor to continually monitor data references from other threads to detect interfering data references.
  13. 37. The apparatus of claim 26, wherein if transactional execution completes without encountering an interfering memory access from another thread, the transactional processing mechanism is configured to:
    commit changes made during the transactional execution to the architectural state of the processor; and to
    resume normal non-transactional execution of the program past the block of instructions.
  14. 38. The apparatus of claim 37, wherein while committing changes made during transactional execution, the transactional processing mechanism is configured to:
    clear load marks from cache lines;
    commit store buffer entries generated during the transactional execution to memory, wherein if a store buffer entry contains a last update made to a cache line during the transactional execution, committing the store buffer entry involves unmarking the corresponding cache line; and to
    commit register file changes made during transactional execution.
  15. 39. The apparatus of claim 26, wherein the request to perform the memory access can include:
    a request-to-own (RTO) signal; or
    a request-to-share (RTS) signal.
  16. 40. A method for delaying memory accesses directed to cache lines associated with transactional execution, comprising:
    commencing transactional execution of a block of instructions within a thread executing on a processor; and
    receiving a request from a requesting thread to perform a memory access involving a cache line;
    wherein if performing the memory access on the cache line will interfere with the transactional execution and if it is possible to delay the memory access, the method further comprises, performing the memory access at a later time when the memory access will not interfere with the transaction.
  17. 41. The method of claim 40, wherein performing the memory access at a later time when the memory access will not interfere with the transaction involves:
    storing copy-back information for the cache line to enable the cache line to be copied back to the requesting thread, and
    performing the memory access and copying the cache line back to the requesting thread at a later time when the memory access will not interfere with the transactional execution.
  18. 42. The method of claim 40, wherein performing the memory access involves copying the cache line back to the requesting thread.
  19. 43. The method of claim 40, wherein it is possible to delay an interfering memory access if a commit operation is in the process of committing updates made during the transactional execution to the architectural state of the processor, and if the memory access is directed to a cache line for which a last update made during the transactional execution has not yet been committed to the architectural state of the processor.
  20. 44. The method of claim 43, wherein a cache line associated with a delayed memory access is copied back to the requesting thread after the last update to the cache line during the transactional execution is committed to the architectural state of the processor.
  21. 45. The method of claim 43, wherein a cache line associated with a delayed memory access is copied back to the requesting thread after all updates that took place during the transactional execution are committed to the architectural state of the processor.
  22. 46. The method of claim 43, wherein it is possible to delay an interfering memory access prior to the commit operation; and
    wherein if the transactional execution fails prior to the commit operation, the method further involves copying back cache lines for any interfering memory accesses that have been delayed during the transactional execution, wherein the data that is copied back is original cache line data, which has not been modified during the transactional execution.
  23. 47. An computer system that facilitates delaying memory accesses directed to cache lines associated with transactional execution, comprising:
    a processor;
    a memory;
    a transactional execution mechanism within the processor configured to commence transactional execution of a block of instructions within a thread executing on a processor; and
    a request processing mechanism within the processor configured to receive a request from a requesting thread to perform a memory access involving a cache line;
    wherein if performing the memory access on the cache line will interfere with the transactional execution and if it is possible to delay the memory access, the request processing mechanism is configured to perform the memory access at a later time when the memory access will not interfere with the transaction.
US11189591 2003-02-13 2005-07-25 Method and apparatus for delaying interfering accesses from other threads during transactional program execution Abandoned US20050262301A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US44712803 true 2003-02-13 2003-02-13
US10737679 US6938130B2 (en) 2003-02-13 2003-12-15 Method and apparatus for delaying interfering accesses from other threads during transactional program execution
US11189591 US20050262301A1 (en) 2003-02-13 2005-07-25 Method and apparatus for delaying interfering accesses from other threads during transactional program execution

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11189591 US20050262301A1 (en) 2003-02-13 2005-07-25 Method and apparatus for delaying interfering accesses from other threads during transactional program execution

Publications (1)

Publication Number Publication Date
US20050262301A1 true true US20050262301A1 (en) 2005-11-24

Family

ID=32853467

Family Applications (2)

Application Number Title Priority Date Filing Date
US10737679 Active 2023-12-25 US6938130B2 (en) 2003-02-13 2003-12-15 Method and apparatus for delaying interfering accesses from other threads during transactional program execution
US11189591 Abandoned US20050262301A1 (en) 2003-02-13 2005-07-25 Method and apparatus for delaying interfering accesses from other threads during transactional program execution

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10737679 Active 2023-12-25 US6938130B2 (en) 2003-02-13 2003-12-15 Method and apparatus for delaying interfering accesses from other threads during transactional program execution

Country Status (3)

Country Link
US (2) US6938130B2 (en)
EP (1) EP1593037A1 (en)
WO (1) WO2004075052A1 (en)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7178062B1 (en) * 2003-03-12 2007-02-13 Sun Microsystems, Inc. Methods and apparatus for executing code while avoiding interference
US20070074213A1 (en) * 2005-09-28 2007-03-29 Zhiqiang Ma Method and apparatus for detecting cross-thread stack access in multithreaded programs
US20080104335A1 (en) * 2006-10-31 2008-05-01 Cypher Robert E Facilitating load reordering through cacheline marking
US20080104326A1 (en) * 2006-10-31 2008-05-01 Cypher Robert E Facilitating store reordering through cacheline marking
US20080215830A1 (en) * 2007-03-01 2008-09-04 International Business Machines Corporation Employing a data structure of readily accessible units of memory to facilitate memory access
US20080243468A1 (en) * 2007-03-30 2008-10-02 International Business Machines Corporation Providing memory consistency in an emulated processing environment
US7747996B1 (en) * 2006-05-25 2010-06-29 Oracle America, Inc. Method of mixed lock-free and locking synchronization
US20110047334A1 (en) * 2009-08-20 2011-02-24 International Business Machines Corporation Checkpointing in Speculative Versioning Caches
US20110047362A1 (en) * 2009-08-19 2011-02-24 International Business Machines Corporation Version Pressure Feedback Mechanisms for Speculative Versioning Caches
US8572577B2 (en) 2008-06-20 2013-10-29 International Business Machines Corporation Monitoring changes to data within a critical section of a threaded program
US9069782B2 (en) 2012-10-01 2015-06-30 The Research Foundation For The State University Of New York System and method for security and privacy aware virtual machine checkpointing
US9767284B2 (en) 2012-09-14 2017-09-19 The Research Foundation For The State University Of New York Continuous run-time validation of program execution: a practical approach
US9767271B2 (en) 2010-07-15 2017-09-19 The Research Foundation For The State University Of New York System and method for validating program execution at run-time

Families Citing this family (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6282637B1 (en) * 1998-12-02 2001-08-28 Sun Microsystems, Inc. Partially executing a pending atomic instruction to unlock resources when cancellation of the instruction occurs
US7120762B2 (en) * 2001-10-19 2006-10-10 Wisconsin Alumni Research Foundation Concurrent execution of critical sections by eliding ownership of locks
US7225299B1 (en) 2003-07-16 2007-05-29 Transmeta Corporation Supporting speculative modification in a data cache
US7340569B2 (en) * 2004-02-10 2008-03-04 Wisconsin Alumni Research Foundation Computer architecture providing transactional, lock-free execution of lock-based programs
US7921407B2 (en) * 2004-08-10 2011-04-05 Oracle America, Inc. System and method for supporting multiple alternative methods for executing transactions
US20060036792A1 (en) * 2004-08-11 2006-02-16 Chien-Yu Chen Method of Reducing Interrupts In a Processor
US7376800B1 (en) 2004-09-14 2008-05-20 Azul Systems, Inc. Speculative multiaddress atomicity
US7840785B1 (en) 2004-09-14 2010-11-23 Azul Systems, Inc. Transparent concurrent atomic execution
US7376798B1 (en) * 2005-04-07 2008-05-20 Transmeta Corporation Memory management methods and systems that support cache consistency
WO2006128062A3 (en) * 2005-05-25 2009-04-16 Terracotta Inc Database caching of queries and stored procedures using database provided facilities for dependency analysis and detected database updates for invalidation
US7395418B1 (en) * 2005-09-22 2008-07-01 Sun Microsystems, Inc. Using a transactional execution mechanism to free up processor resources used by a busy-waiting thread
US8180971B2 (en) 2005-12-09 2012-05-15 University Of Rochester System and method for hardware acceleration of a software transactional memory
US7523266B2 (en) * 2006-02-06 2009-04-21 Sun Microsystems, Inc. Method and apparatus for enforcing memory reference ordering requirements at the L1 cache level
US7519775B2 (en) * 2006-02-23 2009-04-14 Sun Microsystems, Inc. Enforcing memory-reference ordering requirements at the L2 cache level
US7478203B2 (en) * 2006-03-08 2009-01-13 Sun Microsystems, Inc. Technique for eliminating dead stores in a processor
US8595744B2 (en) * 2006-05-18 2013-11-26 Oracle America, Inc. Anticipatory helper thread based code execution
US7617421B2 (en) * 2006-07-27 2009-11-10 Sun Microsystems, Inc. Method and apparatus for reporting failure conditions during transactional execution
US8069440B2 (en) * 2006-10-27 2011-11-29 Oracle America, Inc. Adaptive code through self steered execution
US20080141268A1 (en) * 2006-12-12 2008-06-12 Tirumalai Partha P Utility function execution using scout threads
US9268710B1 (en) 2007-01-18 2016-02-23 Oracle America, Inc. Facilitating efficient transactional memory and atomic operations via cache line marking
US8117403B2 (en) * 2007-05-14 2012-02-14 International Business Machines Corporation Transactional memory system which employs thread assists using address history tables
US9009452B2 (en) 2007-05-14 2015-04-14 International Business Machines Corporation Computing system with transactional memory using millicode assists
US8095741B2 (en) * 2007-05-14 2012-01-10 International Business Machines Corporation Transactional memory computing system with support for chained transactions
US8688920B2 (en) 2007-05-14 2014-04-01 International Business Machines Corporation Computing system with guest code support of transactional memory
US8095750B2 (en) * 2007-05-14 2012-01-10 International Business Machines Corporation Transactional memory system with fast processing of common conflicts
US8321637B2 (en) * 2007-05-14 2012-11-27 International Business Machines Corporation Computing system with optimized support for transactional memory
CN101689143B (en) * 2007-06-20 2012-07-04 富士通株式会社 Cache control device and control method
CN101689142A (en) * 2007-06-20 2010-03-31 富士通株式会社 Information processor, cache memory controller, and memory access sequence assurance method
US8266387B2 (en) * 2007-06-27 2012-09-11 Microsoft Corporation Leveraging transactional memory hardware to accelerate virtualization emulation
US8176253B2 (en) * 2007-06-27 2012-05-08 Microsoft Corporation Leveraging transactional memory hardware to accelerate virtualization and emulation
US9043553B2 (en) * 2007-06-27 2015-05-26 Microsoft Technology Licensing, Llc Leveraging transactional memory hardware to accelerate virtualization and emulation
US7917698B2 (en) * 2007-10-26 2011-03-29 Oracle America, Inc. Method and apparatus for tracking load-marks and store-marks on cache lines
US7966459B2 (en) * 2007-12-31 2011-06-21 Oracle America, Inc. System and method for supporting phased transactional memory modes
US7904668B2 (en) * 2007-12-31 2011-03-08 Oracle America, Inc. Optimistic semi-static transactional memory implementations
US20090187906A1 (en) * 2008-01-23 2009-07-23 Sun Microsystems, Inc. Semi-ordered transactions
US8359587B2 (en) * 2008-05-01 2013-01-22 Oracle America, Inc. Runtime profitability control for speculative automatic parallelization
US8677337B2 (en) * 2008-05-01 2014-03-18 Oracle America, Inc. Static profitability control for speculative automatic parallelization
US9928071B1 (en) 2008-05-02 2018-03-27 Azul Systems, Inc. Enhanced managed runtime environments that support deterministic record and replay
US8739141B2 (en) * 2008-05-19 2014-05-27 Oracle America, Inc. Parallelizing non-countable loops with hardware transactional memory
US20100095286A1 (en) * 2008-10-10 2010-04-15 Kaplan David A Register reduction and liveness analysis techniques for program code
US8001548B2 (en) * 2008-10-20 2011-08-16 Microsoft Corporation Transaction processing for side-effecting actions in transactional memory
US8166481B2 (en) * 2008-10-20 2012-04-24 Microsoft Corporation Transaction processing in transactional memory
US8108610B1 (en) * 2008-10-21 2012-01-31 Nvidia Corporation Cache-based control of atomic operations in conjunction with an external ALU block
US8732407B2 (en) * 2008-11-19 2014-05-20 Oracle America, Inc. Deadlock avoidance during store-mark acquisition
US8612929B2 (en) * 2008-12-10 2013-12-17 Oracle America, Inc. Compiler implementation of lock/unlock using hardware transactional memory
US8528001B2 (en) * 2008-12-15 2013-09-03 Oracle America, Inc. Controlling and dynamically varying automatic parallelization
US20100332768A1 (en) * 2009-06-26 2010-12-30 Microsoft Corporation Flexible read- and write-monitored and buffered memory blocks
US8812796B2 (en) * 2009-06-26 2014-08-19 Microsoft Corporation Private memory regions and coherence optimizations
US8566524B2 (en) 2009-08-31 2013-10-22 International Business Machines Corporation Transactional memory system with efficient cache support
US8561046B2 (en) * 2009-09-14 2013-10-15 Oracle America, Inc. Pipelined parallelization with localized self-helper threading
US20110113409A1 (en) * 2009-11-10 2011-05-12 Rodrick Evans Symbol capabilities support within elf
US8402218B2 (en) 2009-12-15 2013-03-19 Microsoft Corporation Efficient garbage collection and exception handling in a hardware accelerated transactional memory system
US9092253B2 (en) * 2009-12-15 2015-07-28 Microsoft Technology Licensing, Llc Instrumentation of hardware assisted transactional memory system
US9009692B2 (en) * 2009-12-26 2015-04-14 Oracle America, Inc. Minimizing register spills by using register moves
CN102597976B (en) * 2010-01-19 2015-12-16 拉姆伯斯公司 An adaptive time-division multiplexed memory references from a plurality of processor cores
US8438340B2 (en) * 2010-02-18 2013-05-07 International Business Machines Corporation Executing atomic store disjoint instructions
US20110208921A1 (en) * 2010-02-19 2011-08-25 Pohlack Martin T Inverted default semantics for in-speculative-region memory accesses
US8413132B2 (en) * 2010-09-13 2013-04-02 Samsung Electronics Co., Ltd. Techniques for resolving read-after-write (RAW) conflicts using backup area
US8527712B2 (en) 2011-05-13 2013-09-03 Oracle International Corporation Request to own chaining in multi-socketed systems
WO2013147820A1 (en) * 2012-03-29 2013-10-03 Intel Corporation System and method for managing persistence with a multi-level memory hierarchy including non-volatile memory
US20130339702A1 (en) * 2012-06-15 2013-12-19 International Business Machines Corporation Program interruption filtering in transactional execution
US9311251B2 (en) 2012-08-27 2016-04-12 Apple Inc. System cache with sticky allocation
US20140089600A1 (en) * 2012-09-27 2014-03-27 Apple Inc. System cache with data pending state
US20150378939A1 (en) * 2014-06-27 2015-12-31 Analog Devices, Inc. Memory mechanism for providing semaphore functionality in multi-master processing environment
GB2533650A (en) * 2014-12-23 2016-06-29 Advanced Risc Mach Ltd Debugging data processing transactions
US20160378505A1 (en) * 2015-06-26 2016-12-29 International Business Machines Corporation System operation queue for transaction
WO2018021620A1 (en) * 2016-07-26 2018-02-01 주식회사 맴레이 Parallel processing unit, computing device comprising same, and thread group scheduling method

Citations (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5428761A (en) * 1992-03-12 1995-06-27 Digital Equipment Corporation System for achieving atomic non-sequential multi-word operations in shared memory
US5701432A (en) * 1995-10-13 1997-12-23 Sun Microsystems, Inc. Multi-threaded processing system having a cache that is commonly accessible to each thread
US5742785A (en) * 1992-12-18 1998-04-21 International Business Machines Corporation Posting multiple reservations with a conditional store atomic operations in a multiprocessing environment
US5835764A (en) * 1995-06-30 1998-11-10 International Business Machines Corporation Transaction processing system and method having a transactional subsystem integrated within a reduced kernel operating system
US5940827A (en) * 1995-03-31 1999-08-17 Sun Microsystems, Inc. Methods and apparatus for managing a database in a distributed operating environment
US5974438A (en) * 1996-12-31 1999-10-26 Compaq Computer Corporation Scoreboard for cached multi-thread processes
US6021480A (en) * 1996-06-05 2000-02-01 Compaq Computer Corporation Aligning a memory read request with a cache line boundary when the request is for data beginning at a location in the middle of the cache line
US6185577B1 (en) * 1998-06-23 2001-02-06 Oracle Corporation Method and apparatus for incremental undo
US6360220B1 (en) * 1998-08-04 2002-03-19 Microsoft Corporation Lock-free methods and systems for accessing and storing information in an indexed computer data structure having modifiable entries
US20020087810A1 (en) * 2000-12-29 2002-07-04 Boatright Bryan D. System and method for high performance execution of locked memory instructions in a system with distributed memory and a restrictive memory model
US20020124156A1 (en) * 2000-12-29 2002-09-05 Adi Yoaz Using "silent store" information to advance loads
US6460124B1 (en) * 2000-10-20 2002-10-01 Wisconsin Alumni Research Foundation Method of using delays to speed processing of inferred critical program portions
US20020178349A1 (en) * 2001-05-23 2002-11-28 Nec Corporation Processor, multiprocessor system and method for data dependence speculative execution
US20020199066A1 (en) * 2001-06-26 2002-12-26 Shailender Chaudhry Method and apparatus for facilitating speculative loads in a multiprocessor system
US20030066056A1 (en) * 2001-09-28 2003-04-03 Petersen Paul M. Method and apparatus for accessing thread-privatized global storage objects
US20030079094A1 (en) * 2001-10-19 2003-04-24 Ravi Rajwar Concurrent execution of critical sections by eliding ownership of locks
US6578088B2 (en) * 1996-08-29 2003-06-10 Hitachi, Ltd. Automatic address distributing system
US6681311B2 (en) * 2001-07-18 2004-01-20 Ip-First, Llc Translation lookaside buffer that caches memory type information
US20040154012A1 (en) * 2003-01-31 2004-08-05 Hong Wang Safe store for speculative helper threads
US20040162948A1 (en) * 2003-02-13 2004-08-19 Marc Tremblay Method and apparatus for avoiding locks by speculatively executing critical sections
US20040186970A1 (en) * 2002-05-10 2004-09-23 Kekre Anand A. Method and apparatus for creating a virtual data copy
US6918012B2 (en) * 2001-08-28 2005-07-12 Hewlett-Packard Development Company, L.P. Streamlined cache coherency protocol system and method for a multiple processor single chip device
US6941449B2 (en) * 2002-03-04 2005-09-06 Hewlett-Packard Development Company, L.P. Method and apparatus for performing critical tasks using speculative operations

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6148300A (en) * 1998-06-19 2000-11-14 Sun Microsystems, Inc. Hybrid queue and backoff computer resource lock featuring different spin speeds corresponding to multiple-states

Patent Citations (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5428761A (en) * 1992-03-12 1995-06-27 Digital Equipment Corporation System for achieving atomic non-sequential multi-word operations in shared memory
US5742785A (en) * 1992-12-18 1998-04-21 International Business Machines Corporation Posting multiple reservations with a conditional store atomic operations in a multiprocessing environment
US5940827A (en) * 1995-03-31 1999-08-17 Sun Microsystems, Inc. Methods and apparatus for managing a database in a distributed operating environment
US5835764A (en) * 1995-06-30 1998-11-10 International Business Machines Corporation Transaction processing system and method having a transactional subsystem integrated within a reduced kernel operating system
US5701432A (en) * 1995-10-13 1997-12-23 Sun Microsystems, Inc. Multi-threaded processing system having a cache that is commonly accessible to each thread
US6021480A (en) * 1996-06-05 2000-02-01 Compaq Computer Corporation Aligning a memory read request with a cache line boundary when the request is for data beginning at a location in the middle of the cache line
US6578088B2 (en) * 1996-08-29 2003-06-10 Hitachi, Ltd. Automatic address distributing system
US5974438A (en) * 1996-12-31 1999-10-26 Compaq Computer Corporation Scoreboard for cached multi-thread processes
US6185577B1 (en) * 1998-06-23 2001-02-06 Oracle Corporation Method and apparatus for incremental undo
US6360220B1 (en) * 1998-08-04 2002-03-19 Microsoft Corporation Lock-free methods and systems for accessing and storing information in an indexed computer data structure having modifiable entries
US6460124B1 (en) * 2000-10-20 2002-10-01 Wisconsin Alumni Research Foundation Method of using delays to speed processing of inferred critical program portions
US20020124156A1 (en) * 2000-12-29 2002-09-05 Adi Yoaz Using "silent store" information to advance loads
US20020087810A1 (en) * 2000-12-29 2002-07-04 Boatright Bryan D. System and method for high performance execution of locked memory instructions in a system with distributed memory and a restrictive memory model
US20020178349A1 (en) * 2001-05-23 2002-11-28 Nec Corporation Processor, multiprocessor system and method for data dependence speculative execution
US20020199066A1 (en) * 2001-06-26 2002-12-26 Shailender Chaudhry Method and apparatus for facilitating speculative loads in a multiprocessor system
US6681311B2 (en) * 2001-07-18 2004-01-20 Ip-First, Llc Translation lookaside buffer that caches memory type information
US6918012B2 (en) * 2001-08-28 2005-07-12 Hewlett-Packard Development Company, L.P. Streamlined cache coherency protocol system and method for a multiple processor single chip device
US20030066056A1 (en) * 2001-09-28 2003-04-03 Petersen Paul M. Method and apparatus for accessing thread-privatized global storage objects
US20030079094A1 (en) * 2001-10-19 2003-04-24 Ravi Rajwar Concurrent execution of critical sections by eliding ownership of locks
US6941449B2 (en) * 2002-03-04 2005-09-06 Hewlett-Packard Development Company, L.P. Method and apparatus for performing critical tasks using speculative operations
US20040186970A1 (en) * 2002-05-10 2004-09-23 Kekre Anand A. Method and apparatus for creating a virtual data copy
US20040154012A1 (en) * 2003-01-31 2004-08-05 Hong Wang Safe store for speculative helper threads
US20040162948A1 (en) * 2003-02-13 2004-08-19 Marc Tremblay Method and apparatus for avoiding locks by speculatively executing critical sections

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7178062B1 (en) * 2003-03-12 2007-02-13 Sun Microsystems, Inc. Methods and apparatus for executing code while avoiding interference
US20070074213A1 (en) * 2005-09-28 2007-03-29 Zhiqiang Ma Method and apparatus for detecting cross-thread stack access in multithreaded programs
US7844971B2 (en) * 2005-09-28 2010-11-30 Intel Corporation Method and apparatus for detecting cross-thread stack access in multithreaded programs
US7747996B1 (en) * 2006-05-25 2010-06-29 Oracle America, Inc. Method of mixed lock-free and locking synchronization
US20080104335A1 (en) * 2006-10-31 2008-05-01 Cypher Robert E Facilitating load reordering through cacheline marking
US7757044B2 (en) * 2006-10-31 2010-07-13 Oracle America, Inc. Facilitating store reordering through cacheline marking
US7797491B2 (en) * 2006-10-31 2010-09-14 Oracle America, Inc. Facilitating load reordering through cacheline marking
US20080104326A1 (en) * 2006-10-31 2008-05-01 Cypher Robert E Facilitating store reordering through cacheline marking
US20080215830A1 (en) * 2007-03-01 2008-09-04 International Business Machines Corporation Employing a data structure of readily accessible units of memory to facilitate memory access
US20080243468A1 (en) * 2007-03-30 2008-10-02 International Business Machines Corporation Providing memory consistency in an emulated processing environment
US7899663B2 (en) * 2007-03-30 2011-03-01 International Business Machines Corporation Providing memory consistency in an emulated processing environment
US8572577B2 (en) 2008-06-20 2013-10-29 International Business Machines Corporation Monitoring changes to data within a critical section of a threaded program
US20110047362A1 (en) * 2009-08-19 2011-02-24 International Business Machines Corporation Version Pressure Feedback Mechanisms for Speculative Versioning Caches
US8397052B2 (en) 2009-08-19 2013-03-12 International Business Machines Corporation Version pressure feedback mechanisms for speculative versioning caches
US20110047334A1 (en) * 2009-08-20 2011-02-24 International Business Machines Corporation Checkpointing in Speculative Versioning Caches
US8521961B2 (en) 2009-08-20 2013-08-27 International Business Machines Corporation Checkpointing in speculative versioning caches
US9767271B2 (en) 2010-07-15 2017-09-19 The Research Foundation For The State University Of New York System and method for validating program execution at run-time
US9767284B2 (en) 2012-09-14 2017-09-19 The Research Foundation For The State University Of New York Continuous run-time validation of program execution: a practical approach
US9069782B2 (en) 2012-10-01 2015-06-30 The Research Foundation For The State University Of New York System and method for security and privacy aware virtual machine checkpointing
US9552495B2 (en) 2012-10-01 2017-01-24 The Research Foundation For The State University Of New York System and method for security and privacy aware virtual machine checkpointing

Also Published As

Publication number Publication date Type
EP1593037A1 (en) 2005-11-09 application
US20040162951A1 (en) 2004-08-19 application
WO2004075052A1 (en) 2004-09-02 application
US6938130B2 (en) 2005-08-30 grant

Similar Documents

Publication Publication Date Title
Gniady et al. Is sc+ ilp= rc?
US6748518B1 (en) Multi-level multiprocessor speculation mechanism
Rajwar et al. Speculative lock elision: Enabling highly concurrent multithreaded execution
US6963967B1 (en) System and method for enabling weak consistent storage advantage to a firmly consistent storage architecture
US20060161740A1 (en) Transaction based shared data operations in a multiprocessor environment
US8001421B2 (en) Compiler technique for efficient register checkpointing to support transaction roll-back
Hammond et al. Data speculation support for a chip multiprocessor
US6609192B1 (en) System and method for asynchronously overlapping storage barrier operations with old and new storage operations
US6922745B2 (en) Method and apparatus for handling locks
US20110145512A1 (en) Mechanisms To Accelerate Transactions Using Buffered Stores
US20090172317A1 (en) Mechanisms for strong atomicity in a transactional memory system
US8327188B2 (en) Hardware transactional memory acceleration through multiple failure recovery
US20110307689A1 (en) Processor support for hardware transactional memory
US7421544B1 (en) Facilitating concurrent non-transactional execution in a transactional memory system
US20110208921A1 (en) Inverted default semantics for in-speculative-region memory accesses
US6728867B1 (en) Method for comparing returned first load data at memory address regardless of conflicting with first load and any instruction executed between first load and check-point
US6691220B1 (en) Multiprocessor speculation mechanism via a barrier speculation flag
Wenisch et al. Mechanisms for store-wait-free multiprocessors
US20080162885A1 (en) Mechanism for software transactional memory commit/abort in unmanaged runtime environment
US8180977B2 (en) Transactional memory in out-of-order processors
US20070143550A1 (en) Per-set relaxation of cache inclusion
US20070239942A1 (en) Transactional memory virtualization
US6606702B1 (en) Multiprocessor speculation mechanism with imprecise recycling of storage operations
US20120079245A1 (en) Dynamic optimization for conditional commit
US20120079246A1 (en) Apparatus, method, and system for providing a decision mechanism for conditional commits in an atomic region