US7856537B2 - Hybrid hardware and software implementation of transactional memory access - Google Patents

Hybrid hardware and software implementation of transactional memory access Download PDF

Info

Publication number
US7856537B2
US7856537B2 US10/956,179 US95617904A US7856537B2 US 7856537 B2 US7856537 B2 US 7856537B2 US 95617904 A US95617904 A US 95617904A US 7856537 B2 US7856537 B2 US 7856537B2
Authority
US
United States
Prior art keywords
transaction
mode
cache
lock
software
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.)
Active, expires
Application number
US10/956,179
Other versions
US20060085591A1 (en
Inventor
Sanjeev Kumar
Christopher J. Hughes
Partha Kundu
Anthony Nguyen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
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
Priority to US10/956,179 priority Critical patent/US7856537B2/en
Application filed by Intel Corp filed Critical Intel Corp
Assigned to INTEL CORPORATION reassignment INTEL CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HUGHES, CHRISTOPHER J., KUMAR, SANJEEV, KUNDU, PARTHA, NGUYEN, ANTHONY
Priority to PCT/US2005/033917 priority patent/WO2006039174A1/en
Priority to JP2007533617A priority patent/JP4774056B2/en
Priority to DE112005002402.4T priority patent/DE112005002402B4/en
Priority to CN201010144199.7A priority patent/CN101807169B/en
Priority to CN2005101078095A priority patent/CN1755635B/en
Publication of US20060085591A1 publication Critical patent/US20060085591A1/en
Priority to US12/943,848 priority patent/US8661206B2/en
Publication of US7856537B2 publication Critical patent/US7856537B2/en
Application granted granted Critical
Priority to US13/843,890 priority patent/US9529715B2/en
Priority to US15/299,452 priority patent/US10102123B2/en
Priority to US15/477,055 priority patent/US10268579B2/en
Priority to US15/477,052 priority patent/US10180903B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G06F12/0831—Cache consistency protocols using a bus scheme, e.g. with bus monitoring or watching means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/084—Multiuser, multiprocessor or multiprocessing cache systems with a shared cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0844—Multiple simultaneous or quasi-simultaneous cache accessing
    • G06F12/0846—Cache with multiple tag or data arrays being simultaneously accessible
    • G06F12/0848—Partitioned cache, e.g. separate instruction and operand caches
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G06F9/30043—LOAD or STORE instructions; Clear instruction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/30087—Synchronisation or serialisation instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3824—Operand accessing
    • G06F9/3834—Maintaining memory consistency
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
    • G06F9/3858—Result writeback, i.e. updating the architectural state or memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
    • G06F9/3858—Result writeback, i.e. updating the architectural state or memory
    • G06F9/38585—Result writeback, i.e. updating the architectural state or memory with result invalidation, e.g. nullification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G06F9/467—Transactional memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526—Mutual exclusion algorithms
    • G06F9/528—Mutual exclusion algorithms by using speculative mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/60—Details of cache memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/62—Details of cache specific to multiprocessor cache arrangements
    • G06F2212/621—Coherency control relating to peripheral accessing, e.g. from DMA or I/O device

Definitions

  • Embodiments of the invention relate to the field of transactional memory. More particularly, embodiments of the invention relate to a hybrid hardware and software implementation of transactional memory access.
  • Transactional memory service allows applications, programs, modules, etc., and more particularly application program interfaces (APIs), to access memory in an atomic, consistent, and isolated manner.
  • APIs application program interfaces
  • transactional memory may be used as part of a run time engine for managing persistent, pointer-rich data structures, such as databases, and directory services.
  • An API may be thought of as a language or message format used by an application, program, module, etc., to communicate with a system program such as an operating system or a database management system (DBMS). APIs may be implemented by writing function calls in a program, which provide the linkage to a specific subroutine for execution. Thus, an API implies that some program module or routine is either already in place, or is linked to, in order to perform tasks requested by a function call.
  • DBMS database management system
  • Transactional memory makes it easier to write parallel programs and the use of transactional memory allows for different threads to proceed simultaneously thereby gaining extremely high processing efficiencies.
  • the programmer has to make a difficult choice in utilizing transactional memory.
  • TM transactional memory application program interface
  • TM transactional memory
  • a transaction is a group of operations that must satisfy four properties referred to as the ACID properties.
  • the first ACID property is atomicity. Atomicity requires that a database transaction is performed in an all-or-nothing manner. The transaction may be aborted either because the program aborts or due to an error. Atomicity requires that either all of the operations of the transaction are performed or none of them are performed.
  • the second ACID property is consistency. Consistency requires that if the database is in a consistent state before the transaction is performed, the database should be left in a consistent state.
  • the third ACID property is isolation.
  • the isolation property states that all transactions to be performed have to appear to be done in some sort of serial order (i.e., they should be serializable).
  • the last and fourth property required to be under ACID is durability.
  • Durability requires a transaction to survive a machine crash. That is, a transaction has to be written to a stable storage device (e.g. disk) before it can be committed.
  • TM stable storage device
  • durability is not a requirement.
  • transactions and databases utilizing transactional memory are often required to support concurrent execution, deadlock freedom, and non-blocking properties.
  • concurrent execution of non-conflicting transactions is supported by transactional memory systems.
  • Some database implementations use locks (e.g. two phase locking) to implement these types of transactions. Consequently, deadlocks can occur in these cases.
  • Deadlock freedom is implemented in transactional memory systems by, once detecting a deadlock, recovering from a deadlock by simply aborting some of the transactions.
  • the non-blocking or obstruction-freedom property is required to prevent a thread from hindering the progress of other threads in transactional memory systems.
  • the Pure Hardware Approach provides an efficient and easy-to-use lock-free synchronization method.
  • the Pure Hardware Approach avoids many of the subtle correctness problems associated with parallel programming in addition to guaranteeing freedom from priority-inversion, convoying, and deadlocks typically associated with lock-based synchronization methods.
  • the Pure Hardware Approach requires careful resource management by the programmer. As such, the Pure Hardware Approach is very difficult to implement with a wide variety of more advanced processor structures. Typically, software is required to be portable across processor implementation and such careful tuning of resources at the application level limits the use of the pure hardware approach. Furthermore, in operation, the Pure Hardware Approach only utilizes transaction cache in transactional memory, and because of this limited resource, process threads are not guaranteed to complete resulting in program malfunctions.
  • FIG. 1 is a partial block diagram of an example of a computer system configuration, in which embodiments of the invention may be practiced.
  • FIG. 2 is a diagram providing an illustration of a transactional memory object, according to one embodiment of the invention.
  • FIG. 3 is a table illustrating an instruction set architecture to implement hardware/software transactional memory transactions, according to one embodiment of the invention.
  • FIG. 4A is a flow chart illustrating a process for hybrid hardware and software implementation of transactional memory accesses, according to one embodiment of the invention.
  • FIG. 4B is a flow diagram particularly illustrating a process to monitor for orphan transactions, according to one embodiment of the invention.
  • FIG. 5 is a flow diagram illustrating a process to implement locks efficiently utilizing the hardware/software transaction ISA, according to one embodiment of the invention.
  • Embodiments of the invention provide a hybrid hardware and software implementation of transactional memory (TM) accesses, for example, for use with application program interfaces (APIs), to deliver high performance accesses by utilizing the embedded hardware support of the processor and then reverting to a software scheme if the hardware resources become exhausted.
  • TM transactional memory
  • APIs application program interfaces
  • performance penalties associated with TM API software approaches are significantly reduced, as will be discussed, by modifying an original transaction object to enable hardware TM assistance in the most common cases.
  • common cases are processed utilizing embedded hardware support (e.g., transactional memory cache) for high performance, and if a problem arises, a software TM scheme is reverted to if the hardware resources become exhausted.
  • FIG. 1 shows a partial block diagram of an example of a computer system configuration 100 , in which embodiments of the invention may be practiced.
  • the system configuration 100 includes at least one processor 101 such as a central processing unit (CPU), a chipset 103 , system memory devices 105 , one or more interfaces 111 to interface with one or more input/output (I/O) devices 113 , and a network interface 107 .
  • processor 101 such as a central processing unit (CPU), a chipset 103 , system memory devices 105 , one or more interfaces 111 to interface with one or more input/output (I/O) devices 113 , and a network interface 107 .
  • processor 101 such as a central processing unit (CPU), a chipset 103 , system memory devices 105 , one or more interfaces 111 to interface with one or more input/output (I/O) devices 113 , and a network interface 107 .
  • CPU central processing unit
  • the chipset 103 may include a memory control hub (MCH) and/or an I/O control hub.
  • the chipset 103 may be one or more integrated circuit chips that act as a hub or core for data transfer between the processor 101 and other components of the computer system 100 .
  • the computer system 100 may include additional components (not shown) such as other processors (e.g., in a multi-processor system), a co-processor, as well as other components, etc.—this being only a very basic example of a computer system.
  • processors or “CPU” refers to any machine that is capable of executing a sequence of instructions and should be taken to include, but not be limited to, general purpose microprocessors, special purpose microprocessors, application specific integrated circuits (ASICs), multi-media controllers, signal processors, and micro-controllers, etc.
  • the CPU 101 is a general-purpose high-speed microprocessor that is capable of executing an Intel Architecture instruction set.
  • the CPU 101 can be one of the INTEL® PENTIUM® classes of processors, such as INTEL® Architecture 32-bit (IA-32) processor (e.g., PENTIUM® 4M).
  • the CPU 101 , the chipset 103 , and the other components access system memory devices 105 via chipset 103 .
  • the chipset 103 for example, with the use of a memory control hub, may service memory transactions that target system memory devices 105 .
  • System memory devices 105 may include any memory device adapted to store digital information, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), and/or double data rate (DDR) SDRAM or DRAM, etc.
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • SDRAM synchronous dynamic random access memory
  • DDR double data rate SDRAM or DRAM, etc.
  • system memory devices 105 include volatile memory.
  • system memory devices can also include non-volatile memory such as read-only memory (ROM).
  • system memory devices 105 may further include other storage devices such as hard disk drives, floppy disk drives, optical disk drives, etc., and appropriate interfaces.
  • system memory devices 105 may in non-volatile memory store a hardware/software transactional memory (TM) engine program for operation by the processor 101 to implement techniques in accordance with embodiments of the invention for a hybrid hardware/software TM engine implemented at the processor 101 to enable transactional memory accesses and transactions (hereinafter the terms access and transaction are used interchangeably) within computer system 100 .
  • TM hardware/software transactional memory
  • System memory devices may also include regions of memory devoted to implement transactional memory transactions with databases 108 .
  • databases 108 may include such databases as corporate databases, financial databases, project management databases, directory services, etc., and other pointer-rich data structures that are typically utilized with transactional memory type transactions.
  • computer system 100 may include suitable interfaces 111 to interface with I/O devices 113 such as disk drives, monitors, keypads, a modem, a printer, or any other type of suitable I/O devices.
  • I/O devices 113 such as disk drives, monitors, keypads, a modem, a printer, or any other type of suitable I/O devices.
  • Computer system 100 may also include a network interface 107 to interface the computer system 100 with a network 109 such as a local area network (LAN), a wide area network (WAN), the Internet, etc.
  • a network 109 such as a local area network (LAN), a wide area network (WAN), the Internet, etc.
  • the basic computer system configuration 100 of FIG. 1 is an example of one type of computer system that may be utilized in implementing a hybrid hardware and software implementation of transactional memory accesses. It should be appreciated by those skilled in the art that the exemplary FIG. 1 computer system configuration 100 is only one example of a basic computer system and that many other types and variations are possible. Further, those skilled in the art will recognize that the exemplary environment illustrated in FIG. 1 is not intended to limit the embodiments of the invention. Moreover, it should be appreciated that in addition to, or in lieu of, the single computer system configuration 100 , clusters or other groups of computers (similar to or different from computer system configuration 100 ) may be utilized in practicing embodiments of the invention.
  • processor 101 utilizing transactional engine 118 may implement a hybrid hardware/software TM access approach.
  • transactional engine 118 includes standard TM functionality along with an enhanced TM instruction set architecture (ISA) implemented by the transactional engine 118 , as will be discussed in more detail later, to implement embodiments of the invention related to a hybrid hardware/software TM engine.
  • processor 101 includes a transactional cache 132 and a regular memory cache 134 that may be coupled to one another.
  • the TM ISA implemented with transactional engine 118 enables a hybrid hardware/software TM engine for use with, for example, APIs to deliver high performance using hardware support (e.g., transactional cache 132 ) in a “hardware mode”, and reverts to a software scheme (or “software mode”) if hardware cache 132 is exhausted.
  • API requests 116 to read and write data to memory 105 and databases 108 is optimized.
  • hardware mode refers to utilizing mainly the transactional cache 132 for high performance
  • software mode refers to utilizing mainly the regular cache 134 and other memory resources that provide for slower performance but that are not exhaustible.
  • FIG. 2 is a diagram providing an illustration of a transactional memory object, according to one embodiment of the invention.
  • a transactional memory (TM) object 202 is identified by a locator 204 .
  • Each shared data object that is not read-only is placed into a container as shown as TM object 202 .
  • TM object 202 Each shared data object that is not read-only is placed into a container as shown as TM object 202 .
  • TM object 202 During a transaction, all TM objects 202 are opened before they are accessed. This associates the objects with the transaction so that the underlying software system can detect conflicts between transactions.
  • a thread opens an object with an API that specifies whether the object will be accessed in a read-only manner. The data within the transactional object can be manipulated once the object has been opened.
  • the locator 204 functions as the transactional object locator. There is one transactional object locator that is active for each transactional object, regardless of the number of threads simultaneously accessing the object.
  • the state list 206 stores the memory addresses of the states of the transactions currently accessing the object in the software mode. Typically, the state of a transaction is one of: ACTIVE COMMITTED or ABORTED ( 214 ). There is only one state per transaction. Transactions in hardware mode also have a state, but they are never present in the state list 206 , as will be discussed.
  • the TM locator 204 further stores the memory addresses of the contents 218 of the new version of the object 210 and contents 220 of the old version of the object 212 .
  • the version it gets depends on the state of the last transaction that opened the object for writing (i.e., not read-only). If the last writer's state 214 is ACTIVE or ABORTED, the transaction opening the object will receive the old version 220 . If the last writer's state 214 is COMMITTED, the transaction opening the object will receive the new version 218 .
  • a transaction in software mode When a transaction in software mode opens a TM object 202 for writing, it places the address of the latest version (as defined above) in the old object field 212 of the TM locator object 204 . The transaction makes a copy of the latest contents, and places the address of this copy in the new object field 210 of the TM locator 204 . Until the transaction in software mode commits, the new copy of the object is not accessed by any other thread and is therefore local. Once the transaction commits, the new version of the TM object becomes a shared object and cannot be modified anymore. When a transaction in hardware mode opens a TM object 202 for writing, it does not make a copy of the contents. A transaction in hardware mode directly modifies the latest version of the object, relying on hardware to buffer speculative writes, as will be discussed.
  • the TM object 202 further includes a mode field 208 to indicate whether the TM object 202 is in read mode or write mode.
  • a transaction in software mode opens a TM object in either read or write mode 208 , it adds the address of its state variable 214 to the state list 206 . This allows other threads (in both software and hardware modes) to abort the transaction and removes the need to ever do a validation operation on an individual object.
  • a transaction can be validated by simply examining one location that maintains the state of the transaction (state 214 ).
  • a TM object 202 allows for only a single reader or a single writer at a given time. This restriction may be alleviated, in some embodiments, by allowing multiple transaction fields in the state list 206 to allow for concurrent readers. This provides multiple (but bounded) transactions to open an object at any given time. This limit can be set on a per object basis. As will be discussed, the TM object 202 makes transactional memory transactions more amenable to implementation by a hardware/software hybrid scheme.
  • Embodiments of the present invention provide a hardware/software transaction instruction set architecture (ISA) that allows for transactional memory transactions to be either implemented in a “hardware mode” or a “software mode”.
  • ISA hardware/software transaction instruction set architecture
  • a transactional memory access is performed in the hardware mode, it is performed primarily by utilizing the transactional cache 132 ( FIG. 1 ). In this way, very high performance can be delivered to the transaction, however, hardware resources sometimes become exhausted. Further, in the hardware mode the processor needs to track all of the memory locations accessed. In the hardware mode conflicts between simultaneously executing transactions are detected and one of the conflicting transactions is aborted. On an abort, the data written during the transaction is invalidated, and on a commit that data must be atomically part of the memory state.
  • embodiments of the invention relate to a hybrid hardware and software implementation of transactional memory access in a computer system.
  • a processor including a transactional cache and a regular cache is utilized in a computer system.
  • a policy manager selects one of a first mode (hereinafter “hardware mode”) or a second mode (hereinafter “software mode”) to implement transactional memory accesses responsive to an application program interface (API) request to access memory.
  • the transactional cache is utilized to perform read and write memory operations
  • the regular cache is utilized to perform most read and write memory operations (only one location is stored in the transactional cache, as will be discussed).
  • the policy manager first selects the hardware mode to perform read and write operations using transactional read and write instructions in the transactional cache. If sufficient memory resources exist in the transactional cache to perform the read and write operations a commit instruction is issued to complete the transactional memory access. However, if conflicting transactional read and write operations or if insufficient memory resources are detected in the transactional cache, then an abort instruction is issued. If an abort instruction is issued for the first mode, the policy manager may select the software mode in which regular read and write operations are performed using regular read and write instructions in the regular cache.
  • FIG. 3 is a table illustrating an instruction set to implement hardware/software transactional memory transactions, according to one embodiment of the invention.
  • the hardware/software transaction ISA 300 includes a begin transaction 302 having two modes.
  • Begin Transaction All is to designate “hardware mode” transactions whereas the Begin Transaction Select is used for “software mode” transactions.
  • the begin transaction instruction 302 marks the start of a transaction.
  • the Begin Transaction All for “hardware mode” causes all memory accesses to be transactional by default (e.g. utilizing a transactional cache) whereas the Begin Transaction Select makes only the memory operations that are explicitly specified to be transactional.
  • the commit instruction 304 is used to mark the end of a transaction and allows all of the contents of the transactional memory including the transactional cache to become architectural. Particularly, transactional stores are allowed to modify the system state and transactional loads are purged from the transaction cache. A commit transaction cannot be commenced if a prior transaction was not previously started.
  • the abort transaction 306 aborts the current transaction and discards all the transactional write data that was previously being buffered. An error will occur if no transaction was previously started.
  • the hardware/software transaction ISA 300 also includes load/store transaction instructions 308 to perform transactional memory load/store operations.
  • Hardware/software transaction ISA 300 additionally includes load/store regular instructions to perform non-transactional memory load/store operations.
  • Checkpoint and restore state instructions 312 are also provided.
  • the checkpoint instruction checkpoints the current register state to memory.
  • the restore instruction restores the current register state from memory.
  • Hardware/software transaction ISA 300 also includes an orphan transaction exception instruction 314 .
  • a transaction is defined to be an orphan if it cannot commit. For example, this may occur if another process has written to a location that it has read transactionally. In this case, an orphan transaction can see the memory in an inconsistent state and may cause the program to cause an exception such as divide-by-zero or accessing a memory address that is out of range. Worse yet, it could write wrong values to valid memory locations and corrupt the system state.
  • the orphan transaction exception instruction avoids these complications. Particularly, the first load instruction executed by a thread, after its transaction has become an orphan, will generate an orphan transaction exception 314 , as will be discussed.
  • FIG. 4A is a flow chart illustrating a process 400 for a hybrid hardware and software implementation of transactional memory accesses, according to one embodiment of the invention.
  • the process 400 takes advantage of the fact, that when implemented in the “hardware mode” (e.g. utilizing primarily the transactional cache of the processor) for most normal cases, transactional memory accesses are completed in a very rapid and optimal fashion. However, the process also takes into account that when implemented by the processor in hardware mode, the transaction may not be able to be completed and therefore, it falls back into a “software mode” which is always guaranteed to complete the transactions. In contrast, the “software mode” primarily uses regular cache and other memory resources. As will be discussed, when a hardware transaction is invalidated, the next memory operation causes an orphan transaction exception, which prevents the invalidated hardware transaction from proceeding and corrupting memory.
  • a transaction (e.g., from an API) is begun.
  • a policy manager selects either hardware or software mode to begin the transaction.
  • the hardware mode is selected first to take advantage of the rapid hardware processing (e.g., via a transactional cache), and the software mode can be used as a backup.
  • a Begin Transaction All instruction 302 from the hardware/software transaction ISA 300 is initiated such that the mode is set to hardware (block 406 ). Further, a load transaction instruction 308 from the hardware/software transaction ISA is also initiated to load the transactional memory state.
  • read and write operations for the transaction are performed in place on TM objects, as previously discussed, using transactional read and write operations. If the hardware transaction can be completed (e.g., if there are sufficient hardware resources to complete the transaction with the transactional cache), then a commit transaction instruction is generated and, as shown in block 410 , the state is set to commit and the transaction is committed. The process for the transaction has thus been committed (block 415 ).
  • an orphan transaction exception instruction 424 is generated. This may be due to a conflicting transactional read/write operation or insufficient hardware resources. In either case, the transactional memory is cleaned up and the transaction is retried (block 426 ). Typically, if the failure occurred in the hardware mode, then for the next try, the policy manager will select the software mode.
  • the transactional memory may be implemented using a transactional cache.
  • processor 101 may include transactional cache 132 and a regular cache 134 . All locations that are read and written to using load and store transactions 308 from the hardware/software transaction ISA 300 are stored in the transactional cache. All transactional writes stay in the transactional cache until the transaction commits. If a location in the transactional cache that was read by the transaction is written to by a different thread, the transaction becomes an orphan and will eventually be aborted.
  • a commit transaction instruction 304 marks the end of the transaction and allows all the contents of the transaction cache to become architectural (e.g., transactional stores are allowed to modify the system state and transactional loads are purged from the transaction cache).
  • a transaction is defined to be an orphan if it cannot commit. For instance, a transaction may be orphaned if another thread wrote to a location that it read. An orphan transaction can see the memory in an inconsistent state and cause the processor to cause an exception like divide-by-zero or an access to a memory location that is out of range. Worse yet, it could possibly write wrong values to valid memory locations and corrupt the system state. Therefore, when this occurs, an orphan transaction exception instruction 314 is initiated and the action is aborted 422 .
  • the process 400 and the hardware/software transaction ISA 300 allows exceptions to be used asynchronously to notify a thread if the transaction it is executing has become an orphan. Once a transaction has become orphaned, the thread is aborted, and the thread is not allowed to consume data returned from new load operations from memory.
  • a special exception is utilized on every load. Particularly, the first load after a thread is orphaned forces an exception on the load, and the thread is aborted. An exception handler is then responsible for branching back to the beginning of the transaction, which may be accomplished as previously discussed as cleanup and retry block 426 .
  • a user exception handler implemented with the abort transaction instruction 306 is responsible for aborting the transaction and unwinding the stack and restarting the aborted transaction utilizing cleanup and retry 426 .
  • FIG. 4B is a flow diagram particularly illustrating a process 448 to monitor for orphan transactions.
  • a status flag is set to transaction valid.
  • the process 448 monitors for a conflict from by another processor or thread (block 452 ). If a conflict is not detected at block 454 then continued processing occurs (block 456 ). However, if at block 454 a conflict is detected, then the status flag is reset to transaction invalid to mark that the transaction has been aborted (block 460 ). All loads subsequent to the first load transaction check the status flag to verify that it is set to transaction valid before committing (e.g., returning data to the processor). On the other hand, if the status flag is reset, the load is not allowed to be committed and the abort process previously discussed occurs.
  • a Begin Transaction Select instruction 302 is initiated from the hardware/software transaction ISA 300 such that the mode is set to software and the transaction state is loaded. It should be noted that when running in software mode, the processor does not treat all memory accesses as transactional. For each transaction, only one location is accessed in a transactional fashion (e.g., utilizing load transaction instructions 308 )—the location that contains the state of the transaction.
  • read and write operations are performed for the transaction by copying and using regular read and write operations (e.g. load/store regular instructions 310 ). Further, the regular cache and other memory resources are utilized instead of the transactional cache. If the read and write operations for the transaction can be performed, a commit transaction instruction 304 is initiated and the state is set to commit (block 434 ). Thus, the read and write operations to memory are committed (block 415 ).
  • regular read and write operations e.g. load/store regular instructions 310 .
  • the regular cache and other memory resources are utilized instead of the transactional cache.
  • the process may be aborted and the state set to abort (block 436 ).
  • the transaction at block 422 is aborted and based on the exception of a conflicting write transaction 438 , the process 400 in the software mode, may clean up and retry (block 440 ) the transactional operation again in the software mode.
  • the previously discussed hardware/software transaction ISA 300 may be utilized to implement locks efficiently. Briefly, when a lock acquire function is invoked, the processor tries to execute the critical section (e.g., the code between the lock acquire and the subsequent lock release) in the hardware mode using transactional memory extensions, and if this fails, the process reverts back to the software mode.
  • the critical section e.g., the code between the lock acquire and the subsequent lock release
  • a critical section may fail to complete in the hardware mode. For example, resource exhaustion may occur, in which the transactional cache used to maintain the transactional state overflows.
  • resource exhaustion may occur, in which the transactional cache used to maintain the transactional state overflows.
  • there may be a collision on data For example, if two threads try to execute their critical section in the hardware mode and attempt to perform conflicting operations on the same data, this may also cause a failure. For instance, one thread may write to a cache line that the other thread has already read.
  • there may be a failure in the transition to the software mode For example, if a thread grabs a lock in the software mode, all the other threads that were in the middle of the critical section that require that lock will be aborted.
  • a thread checks to make sure that a lock is available and enters the critical section without marking it as locked.
  • a thread checks to make sure that a lock is available and marks it as locked. This will abort any threads that are already in the critical section in the hardware mode and will prevent any new threads from entering the critical section in either the hardware or the software mode.
  • FIG. 5 is a flow diagram illustrating a process 500 to implement locks efficiently utilizing the hardware/software transaction ISA 300 , according to one embodiment of the invention.
  • a lock is acquired or initiated.
  • the policy manager selects a mode.
  • the hardware mode is first chosen to try to most efficiently accomplish the transactional memory transactions.
  • the software mode is then reverted to if the hardware mode cannot complete the transaction.
  • the lock is begun and the mode is set to hardware by the Begin Transaction All instruction 302 of the transaction ISA 300 .
  • the read and write operations are performed for the transaction (e.g. in the transactional cache) using transactional read and write operations (e.g. load/store transactions 308 ). If the transaction is completed then the lock is released (block 510 ) and the transaction is committed.
  • a policy manager selects the software mode.
  • the lock is begun in the software mode and the lock's state is set to lock (block 530 ).
  • the read and write operations are performed using regular read and write operations (e.g. load and store regular instructions 310 ).
  • regular read and write operations e.g. load and store regular instructions 310 .
  • the lock is typically always completed and the lock is then released and the lock state is set to unlock at block 534 . This completes the process 500 .
  • the processor may perform conflict resolution. Particularly, when a data conflict is detected, the processor may resolve the conflict and allow one of the transactions to complete. The remaining conflicting transactions may be deferred or aborted dependent upon whether the any of memory locations they have read have been written to by another thread. Furthermore, when an exception 520 (e.g. an orphan transaction exception) has occurred as previously discussed, a record may be made as to whether the transaction was orphaned due to resource exhaustion or due to a data conflict. An exception handler may then be modified to fall back in the software mode only when the resource is exhausted. When only a data conflict has occurred, a modification may be implemented in which the transaction is retried again in the hardware mode, instead of automatically switching to the software mode.
  • exception 520 e.g. an orphan transaction exception
  • the embodiments of the present invention can be implemented in hardware, software, firmware, middleware or a combination thereof and utilized in systems, subsystems, components, or sub-components thereof.
  • the elements of the present invention are the instructions/code segments to perform the necessary tasks.
  • the program or code segments can be stored in a machine readable medium (e.g. a processor readable medium or a computer program product), or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium or communication link.
  • the machine-readable medium may include any medium that can store or transfer information in a form readable and executable by a machine (e.g. a processor, a computer, etc.).
  • Examples of the machine-readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable programmable ROM (EPROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc.
  • the computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, bar codes, etc.
  • the code segments may be downloaded via networks such as the Internet, Intranet, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Advance Control (AREA)

Abstract

Embodiments of the invention relate a hybrid hardware and software implementation of transactional memory accesses in a computer system. A processor including a transactional cache and a regular cache is utilized in a computer system that includes a policy manager to select one of a first mode (a hardware mode) or a second mode (a software mode) to implement transactional memory accesses. In the hardware mode the transactional cache is utilized to perform read and write memory operations and in the software mode the regular cache is utilized to perform read and write memory operations.

Description

BACKGROUND
1. Field
Embodiments of the invention relate to the field of transactional memory. More particularly, embodiments of the invention relate to a hybrid hardware and software implementation of transactional memory access.
2. Description of Related Art
Transactional memory service allows applications, programs, modules, etc., and more particularly application program interfaces (APIs), to access memory in an atomic, consistent, and isolated manner. For example, transactional memory may be used as part of a run time engine for managing persistent, pointer-rich data structures, such as databases, and directory services.
An API may be thought of as a language or message format used by an application, program, module, etc., to communicate with a system program such as an operating system or a database management system (DBMS). APIs may be implemented by writing function calls in a program, which provide the linkage to a specific subroutine for execution. Thus, an API implies that some program module or routine is either already in place, or is linked to, in order to perform tasks requested by a function call.
Transactional memory makes it easier to write parallel programs and the use of transactional memory allows for different threads to proceed simultaneously thereby gaining extremely high processing efficiencies. However, currently the programmer has to make a difficult choice in utilizing transactional memory.
One choice is to use a hardware-only implementation of a transactional memory application program interface (API) where the programmer is responsible to keep track of a program's hardware resource requirements and ensure that they do not exceed the hardware resources available. The applicability and usability of transactional memory (hereinafter TM) is limited under this approach. The alternative is to use a software-only implementation of TM API that is easy to program (because there is practically no resource limit) but the software approach suffers from high execution time overheads.
Looking more particularly at transactional memory (TM), TM is derived from database transactions. In databases, a transaction is a group of operations that must satisfy four properties referred to as the ACID properties. The first ACID property is atomicity. Atomicity requires that a database transaction is performed in an all-or-nothing manner. The transaction may be aborted either because the program aborts or due to an error. Atomicity requires that either all of the operations of the transaction are performed or none of them are performed. The second ACID property is consistency. Consistency requires that if the database is in a consistent state before the transaction is performed, the database should be left in a consistent state. The third ACID property is isolation. The isolation property states that all transactions to be performed have to appear to be done in some sort of serial order (i.e., they should be serializable). The last and fourth property required to be under ACID is durability. Durability requires a transaction to survive a machine crash. That is, a transaction has to be written to a stable storage device (e.g. disk) before it can be committed. However, it should be noted that not all implementations of TM, require a transaction to satisfy all of the four above-described properties. For example, in some implementations, durability is not a requirement.
Beyond being compliant with all or some of the above-described ACID properties, transactions and databases utilizing transactional memory are often required to support concurrent execution, deadlock freedom, and non-blocking properties. Typically, concurrent execution of non-conflicting transactions is supported by transactional memory systems. Some database implementations use locks (e.g. two phase locking) to implement these types of transactions. Consequently, deadlocks can occur in these cases. Deadlock freedom is implemented in transactional memory systems by, once detecting a deadlock, recovering from a deadlock by simply aborting some of the transactions. The non-blocking or obstruction-freedom property is required to prevent a thread from hindering the progress of other threads in transactional memory systems.
To date, there are two common approaches to implement transactional memory accesses utilizing application program interfaces (APIs): one of which is a purely hardware implementation; and the other of which is a purely software implementation. The hardware implementation is based on a multi-processor architecture as set forth in Transactional Memory: Architectural Support for Lock-Free Data Structures (Maurice Herlihy, J. Eliot B. Moss: Transactional Memory: Architectural Support for Lock-Free Data Structures, International Society for Computers and Their Application, (ISCA) 1993: 289-300). This approach will be hereinafter referred to as the Pure Hardware Approach.
The Pure Hardware Approach provides an efficient and easy-to-use lock-free synchronization method. The Pure Hardware Approach avoids many of the subtle correctness problems associated with parallel programming in addition to guaranteeing freedom from priority-inversion, convoying, and deadlocks typically associated with lock-based synchronization methods.
Unfortunately, the Pure Hardware Approach requires careful resource management by the programmer. As such, the Pure Hardware Approach is very difficult to implement with a wide variety of more advanced processor structures. Typically, software is required to be portable across processor implementation and such careful tuning of resources at the application level limits the use of the pure hardware approach. Furthermore, in operation, the Pure Hardware Approach only utilizes transaction cache in transactional memory, and because of this limited resource, process threads are not guaranteed to complete resulting in program malfunctions.
Another common approach of utilizing transactional memory accesses with APIs is by utilizing a purely software approach, for example, as set forth in Software Transactional Memory for Dynamic-Sized Data Structures (Maurice Herlihy, Victor Luchangco, Mark Moir, William N. Scherer III, Software Transactional Memory for Dynamic-Sized Data Structures, Principles of Distributed Computing (PODC) 2003.) This approach will be hereinafter called The Pure Software Approach. The power of the Pure Software Approach is that the programmer may be completely oblivious of the specific techniques employed to provide transactional memory semantics and the API is particularly easy to program. Unfortunately, in operation, the Pure Software Approach technique results in significant slow-downs caused by software overheads.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a partial block diagram of an example of a computer system configuration, in which embodiments of the invention may be practiced.
FIG. 2 is a diagram providing an illustration of a transactional memory object, according to one embodiment of the invention.
FIG. 3 is a table illustrating an instruction set architecture to implement hardware/software transactional memory transactions, according to one embodiment of the invention.
FIG. 4A is a flow chart illustrating a process for hybrid hardware and software implementation of transactional memory accesses, according to one embodiment of the invention.
FIG. 4B is a flow diagram particularly illustrating a process to monitor for orphan transactions, according to one embodiment of the invention.
FIG. 5 is a flow diagram illustrating a process to implement locks efficiently utilizing the hardware/software transaction ISA, according to one embodiment of the invention.
 DESCRIPTION
In the following description, the various embodiments of the invention will be described in detail. However, such details are included to facilitate understanding of the invention and to describe exemplary embodiments for employing the invention. Such details should not be used to limit the invention to the particular embodiments described because other variations and embodiments are possible while staying within the scope of the invention. Furthermore, although numerous details are set forth in order to provide a thorough understanding of the embodiments of the invention, it will be apparent to one skilled in the art that these specific details are not required in order to practice the embodiments of the invention. In other instances details such as, well-known methods, types of data, protocols, procedures, components, electrical structures and circuits, are not described in detail, or are shown in block diagram form, in order not to obscure the invention. Furthermore, embodiments of the invention will be described in particular embodiments but may be implemented in hardware, software, firmware, middleware, or a combination thereof.
Embodiments of the invention provide a hybrid hardware and software implementation of transactional memory (TM) accesses, for example, for use with application program interfaces (APIs), to deliver high performance accesses by utilizing the embedded hardware support of the processor and then reverting to a software scheme if the hardware resources become exhausted. Thus, the benefits of hardware TM accesses and software TM accesses are simultaneously realized.
In one embodiment, performance penalties associated with TM API software approaches are significantly reduced, as will be discussed, by modifying an original transaction object to enable hardware TM assistance in the most common cases. Thus, common cases are processed utilizing embedded hardware support (e.g., transactional memory cache) for high performance, and if a problem arises, a software TM scheme is reverted to if the hardware resources become exhausted.
FIG. 1 shows a partial block diagram of an example of a computer system configuration 100, in which embodiments of the invention may be practiced. The system configuration 100 includes at least one processor 101 such as a central processing unit (CPU), a chipset 103, system memory devices 105, one or more interfaces 111 to interface with one or more input/output (I/O) devices 113, and a network interface 107.
The chipset 103 may include a memory control hub (MCH) and/or an I/O control hub. The chipset 103 may be one or more integrated circuit chips that act as a hub or core for data transfer between the processor 101 and other components of the computer system 100. Further, the computer system 100 may include additional components (not shown) such as other processors (e.g., in a multi-processor system), a co-processor, as well as other components, etc.—this being only a very basic example of a computer system.
For the purposes of the present description, the term “processor” or “CPU” refers to any machine that is capable of executing a sequence of instructions and should be taken to include, but not be limited to, general purpose microprocessors, special purpose microprocessors, application specific integrated circuits (ASICs), multi-media controllers, signal processors, and micro-controllers, etc. In one embodiment, the CPU 101 is a general-purpose high-speed microprocessor that is capable of executing an Intel Architecture instruction set. For example, the CPU 101 can be one of the INTEL® PENTIUM® classes of processors, such as INTEL® Architecture 32-bit (IA-32) processor (e.g., PENTIUM® 4M).
The CPU 101, the chipset 103, and the other components access system memory devices 105 via chipset 103. The chipset 103, for example, with the use of a memory control hub, may service memory transactions that target system memory devices 105.
System memory devices 105 may include any memory device adapted to store digital information, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), and/or double data rate (DDR) SDRAM or DRAM, etc. Thus, in one embodiment, system memory devices 105 include volatile memory. Further, system memory devices can also include non-volatile memory such as read-only memory (ROM).
Moreover, system memory devices 105 may further include other storage devices such as hard disk drives, floppy disk drives, optical disk drives, etc., and appropriate interfaces.
Additionally, system memory devices 105 may in non-volatile memory store a hardware/software transactional memory (TM) engine program for operation by the processor 101 to implement techniques in accordance with embodiments of the invention for a hybrid hardware/software TM engine implemented at the processor 101 to enable transactional memory accesses and transactions (hereinafter the terms access and transaction are used interchangeably) within computer system 100.
System memory devices may also include regions of memory devoted to implement transactional memory transactions with databases 108. For example, databases 108 may include such databases as corporate databases, financial databases, project management databases, directory services, etc., and other pointer-rich data structures that are typically utilized with transactional memory type transactions.
Further, computer system 100 may include suitable interfaces 111 to interface with I/O devices 113 such as disk drives, monitors, keypads, a modem, a printer, or any other type of suitable I/O devices.
Computer system 100 may also include a network interface 107 to interface the computer system 100 with a network 109 such as a local area network (LAN), a wide area network (WAN), the Internet, etc.
The basic computer system configuration 100 of FIG. 1 is an example of one type of computer system that may be utilized in implementing a hybrid hardware and software implementation of transactional memory accesses. It should be appreciated by those skilled in the art that the exemplary FIG. 1 computer system configuration 100 is only one example of a basic computer system and that many other types and variations are possible. Further, those skilled in the art will recognize that the exemplary environment illustrated in FIG. 1 is not intended to limit the embodiments of the invention. Moreover, it should be appreciated that in addition to, or in lieu of, the single computer system configuration 100, clusters or other groups of computers (similar to or different from computer system configuration 100) may be utilized in practicing embodiments of the invention.
More particularly, as shown in FIG. 1, processor 101 utilizing transactional engine 118 may implement a hybrid hardware/software TM access approach. Particularly, transactional engine 118 includes standard TM functionality along with an enhanced TM instruction set architecture (ISA) implemented by the transactional engine 118, as will be discussed in more detail later, to implement embodiments of the invention related to a hybrid hardware/software TM engine. Also, processor 101 includes a transactional cache 132 and a regular memory cache 134 that may be coupled to one another.
As will be discussed in more detail later, the TM ISA implemented with transactional engine 118 enables a hybrid hardware/software TM engine for use with, for example, APIs to deliver high performance using hardware support (e.g., transactional cache 132) in a “hardware mode”, and reverts to a software scheme (or “software mode”) if hardware cache 132 is exhausted. In this way, API requests 116 to read and write data to memory 105 and databases 108 is optimized. It should be noted that hereinafter “hardware mode” refers to utilizing mainly the transactional cache 132 for high performance whereas “software mode” refers to utilizing mainly the regular cache 134 and other memory resources that provide for slower performance but that are not exhaustible.
While embodiments of the invention and its various functional components have, and will be described, in particular embodiments, it should be appreciated these aspects and functionalities can be implemented in hardware, software, firmware, middleware or a combination thereof.
Turning now to FIG. 2, FIG. 2 is a diagram providing an illustration of a transactional memory object, according to one embodiment of the invention. As shown in FIG. 2, a transactional memory (TM) object 202 is identified by a locator 204. Each shared data object that is not read-only is placed into a container as shown as TM object 202. During a transaction, all TM objects 202 are opened before they are accessed. This associates the objects with the transaction so that the underlying software system can detect conflicts between transactions. Typically, a thread opens an object with an API that specifies whether the object will be accessed in a read-only manner. The data within the transactional object can be manipulated once the object has been opened.
The locator 204 functions as the transactional object locator. There is one transactional object locator that is active for each transactional object, regardless of the number of threads simultaneously accessing the object. The state list 206 stores the memory addresses of the states of the transactions currently accessing the object in the software mode. Typically, the state of a transaction is one of: ACTIVE COMMITTED or ABORTED (214). There is only one state per transaction. Transactions in hardware mode also have a state, but they are never present in the state list 206, as will be discussed.
The TM locator 204 further stores the memory addresses of the contents 218 of the new version of the object 210 and contents 220 of the old version of the object 212. When a transaction opens a TM object to get the latest version of the contents, the version it gets depends on the state of the last transaction that opened the object for writing (i.e., not read-only). If the last writer's state 214 is ACTIVE or ABORTED, the transaction opening the object will receive the old version 220. If the last writer's state 214 is COMMITTED, the transaction opening the object will receive the new version 218.
When a transaction in software mode opens a TM object 202 for writing, it places the address of the latest version (as defined above) in the old object field 212 of the TM locator object 204. The transaction makes a copy of the latest contents, and places the address of this copy in the new object field 210 of the TM locator 204. Until the transaction in software mode commits, the new copy of the object is not accessed by any other thread and is therefore local. Once the transaction commits, the new version of the TM object becomes a shared object and cannot be modified anymore. When a transaction in hardware mode opens a TM object 202 for writing, it does not make a copy of the contents. A transaction in hardware mode directly modifies the latest version of the object, relying on hardware to buffer speculative writes, as will be discussed.
The TM object 202 further includes a mode field 208 to indicate whether the TM object 202 is in read mode or write mode. When a transaction in software mode opens a TM object in either read or write mode 208, it adds the address of its state variable 214 to the state list 206. This allows other threads (in both software and hardware modes) to abort the transaction and removes the need to ever do a validation operation on an individual object. A transaction can be validated by simply examining one location that maintains the state of the transaction (state 214). When a transaction opens a TM object 202 and its mode field 208 is set to read-only, no transactions need to be explicitly aborted if the object is being opened in read-only mode; however, if the object is being opened in write mode, all transactions in the state list 206 need to be aborted if their state 214 is ACTIVE. When a transaction opens a TM object 202 and the mode field 208 is already set to write by the single transaction in the state list 206 (the current writer), this single transaction needs to be aborted if its value is ACTIVE 214, regardless of whether the TM object 202 is being opened in read-only or write mode.
In this implementation, a TM object 202 allows for only a single reader or a single writer at a given time. This restriction may be alleviated, in some embodiments, by allowing multiple transaction fields in the state list 206 to allow for concurrent readers. This provides multiple (but bounded) transactions to open an object at any given time. This limit can be set on a per object basis. As will be discussed, the TM object 202 makes transactional memory transactions more amenable to implementation by a hardware/software hybrid scheme.
Embodiments of the present invention provide a hardware/software transaction instruction set architecture (ISA) that allows for transactional memory transactions to be either implemented in a “hardware mode” or a “software mode”. When a transactional memory access is performed in the hardware mode, it is performed primarily by utilizing the transactional cache 132 (FIG. 1). In this way, very high performance can be delivered to the transaction, however, hardware resources sometimes become exhausted. Further, in the hardware mode the processor needs to track all of the memory locations accessed. In the hardware mode conflicts between simultaneously executing transactions are detected and one of the conflicting transactions is aborted. On an abort, the data written during the transaction is invalidated, and on a commit that data must be atomically part of the memory state.
More particularly, embodiments of the invention relate to a hybrid hardware and software implementation of transactional memory access in a computer system. A processor including a transactional cache and a regular cache is utilized in a computer system. A policy manager selects one of a first mode (hereinafter “hardware mode”) or a second mode (hereinafter “software mode”) to implement transactional memory accesses responsive to an application program interface (API) request to access memory. In the hardware mode the transactional cache is utilized to perform read and write memory operations and in the software mode the regular cache is utilized to perform most read and write memory operations (only one location is stored in the transactional cache, as will be discussed).
The policy manager first selects the hardware mode to perform read and write operations using transactional read and write instructions in the transactional cache. If sufficient memory resources exist in the transactional cache to perform the read and write operations a commit instruction is issued to complete the transactional memory access. However, if conflicting transactional read and write operations or if insufficient memory resources are detected in the transactional cache, then an abort instruction is issued. If an abort instruction is issued for the first mode, the policy manager may select the software mode in which regular read and write operations are performed using regular read and write instructions in the regular cache.
When implementing transactional memory transactions purely in hardware, there is a limit to the number of memory locations that a single transaction can access. If a transaction exceeds this limit, according to one embodiment of the invention, the transaction restarts in the “software mode”. As will be discussed, when a hardware transaction is invalidated, the next memory operation executed by that thread will cause an exception. This prevents an invalidated hardware transaction from proceeding and corrupting memory. After the exception, and entry into the software mode, transactional memory accesses are performed primarily by the regular cache and other memory resources (see FIG. 1).
In order to implement this hybrid hardware and software implementation for transactional memory accesses, embodiments of the invention provide a novel and non-obvious transactional memory instruction set architecture (ISA). With reference to FIG. 3, FIG. 3 is a table illustrating an instruction set to implement hardware/software transactional memory transactions, according to one embodiment of the invention.
As shown in FIG. 3, the hardware/software transaction ISA 300 includes a begin transaction 302 having two modes. Begin Transaction All is to designate “hardware mode” transactions whereas the Begin Transaction Select is used for “software mode” transactions. Particularly, the begin transaction instruction 302 marks the start of a transaction. The Begin Transaction All for “hardware mode” causes all memory accesses to be transactional by default (e.g. utilizing a transactional cache) whereas the Begin Transaction Select makes only the memory operations that are explicitly specified to be transactional.
It should be noted that hardware transactions cannot be nested (as opposed to software-based transactions). Therefore, a new hardware transaction cannot be commenced before a previous transaction has been either committed or aborted. A transaction is aborted either by executing an abort transaction instruction 306 or on encountering a data conflict, as will be discussed.
The commit instruction 304 is used to mark the end of a transaction and allows all of the contents of the transactional memory including the transactional cache to become architectural. Particularly, transactional stores are allowed to modify the system state and transactional loads are purged from the transaction cache. A commit transaction cannot be commenced if a prior transaction was not previously started.
The abort transaction 306 aborts the current transaction and discards all the transactional write data that was previously being buffered. An error will occur if no transaction was previously started.
Further, the hardware/software transaction ISA 300 also includes load/store transaction instructions 308 to perform transactional memory load/store operations.
Hardware/software transaction ISA 300 additionally includes load/store regular instructions to perform non-transactional memory load/store operations.
Checkpoint and restore state instructions 312 are also provided. The checkpoint instruction checkpoints the current register state to memory. The restore instruction restores the current register state from memory.
Hardware/software transaction ISA 300 also includes an orphan transaction exception instruction 314. A transaction is defined to be an orphan if it cannot commit. For example, this may occur if another process has written to a location that it has read transactionally. In this case, an orphan transaction can see the memory in an inconsistent state and may cause the program to cause an exception such as divide-by-zero or accessing a memory address that is out of range. Worse yet, it could write wrong values to valid memory locations and corrupt the system state.
The orphan transaction exception instruction avoids these complications. Particularly, the first load instruction executed by a thread, after its transaction has become an orphan, will generate an orphan transaction exception 314, as will be discussed.
Turning now to FIG. 4A, FIG. 4A is a flow chart illustrating a process 400 for a hybrid hardware and software implementation of transactional memory accesses, according to one embodiment of the invention. The process 400 takes advantage of the fact, that when implemented in the “hardware mode” (e.g. utilizing primarily the transactional cache of the processor) for most normal cases, transactional memory accesses are completed in a very rapid and optimal fashion. However, the process also takes into account that when implemented by the processor in hardware mode, the transaction may not be able to be completed and therefore, it falls back into a “software mode” which is always guaranteed to complete the transactions. In contrast, the “software mode” primarily uses regular cache and other memory resources. As will be discussed, when a hardware transaction is invalidated, the next memory operation causes an orphan transaction exception, which prevents the invalidated hardware transaction from proceeding and corrupting memory.
Looking particularly at process 400, at block 402, a transaction (e.g., from an API) is begun. At block 404, a policy manager selects either hardware or software mode to begin the transaction. In one embodiment, the hardware mode is selected first to take advantage of the rapid hardware processing (e.g., via a transactional cache), and the software mode can be used as a backup.
After selection of the hardware mode, a Begin Transaction All instruction 302 from the hardware/software transaction ISA 300 is initiated such that the mode is set to hardware (block 406). Further, a load transaction instruction 308 from the hardware/software transaction ISA is also initiated to load the transactional memory state. Next, at block 408, read and write operations for the transaction are performed in place on TM objects, as previously discussed, using transactional read and write operations. If the hardware transaction can be completed (e.g., if there are sufficient hardware resources to complete the transaction with the transactional cache), then a commit transaction instruction is generated and, as shown in block 410, the state is set to commit and the transaction is committed. The process for the transaction has thus been committed (block 415).
However, if the transaction cannot be committed in hardware (e.g., there are not sufficient hardware resources in the transactional cache) then an abort transaction instruction is initiated and the state is set to abort and the transaction is aborted (block 420). Thus, the process is aborted (block 422).
When the transaction is aborted, an orphan transaction exception instruction 424 is generated. This may be due to a conflicting transactional read/write operation or insufficient hardware resources. In either case, the transactional memory is cleaned up and the transaction is retried (block 426). Typically, if the failure occurred in the hardware mode, then for the next try, the policy manager will select the software mode.
Briefly, the commit and abort instructions will be discussed in more detail. Particularly, as previously discussed, the transactional memory may be implemented using a transactional cache. For example, as shown in FIG. 1, processor 101 may include transactional cache 132 and a regular cache 134. All locations that are read and written to using load and store transactions 308 from the hardware/software transaction ISA 300 are stored in the transactional cache. All transactional writes stay in the transactional cache until the transaction commits. If a location in the transactional cache that was read by the transaction is written to by a different thread, the transaction becomes an orphan and will eventually be aborted.
A commit transaction instruction 304 marks the end of the transaction and allows all the contents of the transaction cache to become architectural (e.g., transactional stores are allowed to modify the system state and transactional loads are purged from the transaction cache).
A transaction is defined to be an orphan if it cannot commit. For instance, a transaction may be orphaned if another thread wrote to a location that it read. An orphan transaction can see the memory in an inconsistent state and cause the processor to cause an exception like divide-by-zero or an access to a memory location that is out of range. Worse yet, it could possibly write wrong values to valid memory locations and corrupt the system state. Therefore, when this occurs, an orphan transaction exception instruction 314 is initiated and the action is aborted 422.
Thus, the process 400 and the hardware/software transaction ISA 300 allows exceptions to be used asynchronously to notify a thread if the transaction it is executing has become an orphan. Once a transaction has become orphaned, the thread is aborted, and the thread is not allowed to consume data returned from new load operations from memory.
In order to accomplish this, a special exception is utilized on every load. Particularly, the first load after a thread is orphaned forces an exception on the load, and the thread is aborted. An exception handler is then responsible for branching back to the beginning of the transaction, which may be accomplished as previously discussed as cleanup and retry block 426. Thus, a user exception handler implemented with the abort transaction instruction 306 is responsible for aborting the transaction and unwinding the stack and restarting the aborted transaction utilizing cleanup and retry 426.
With brief reference to FIG. 4B, FIG. 4B is a flow diagram particularly illustrating a process 448 to monitor for orphan transactions. At block 450, upon a load transaction, a status flag is set to transaction valid. Next, the process 448 monitors for a conflict from by another processor or thread (block 452). If a conflict is not detected at block 454 then continued processing occurs (block 456). However, if at block 454 a conflict is detected, then the status flag is reset to transaction invalid to mark that the transaction has been aborted (block 460). All loads subsequent to the first load transaction check the status flag to verify that it is set to transaction valid before committing (e.g., returning data to the processor). On the other hand, if the status flag is reset, the load is not allowed to be committed and the abort process previously discussed occurs.
Returning back to FIG. 4A, assuming a hardware transaction has been aborted due to a conflicting transaction read/write operation or the exhaustion of hardware resources the policy manager at block 404 may select the “software mode” to ensure completion of the transaction. At block 430 a Begin Transaction Select instruction 302 is initiated from the hardware/software transaction ISA 300 such that the mode is set to software and the transaction state is loaded. It should be noted that when running in software mode, the processor does not treat all memory accesses as transactional. For each transaction, only one location is accessed in a transactional fashion (e.g., utilizing load transaction instructions 308)—the location that contains the state of the transaction.
Next, at block 432, read and write operations are performed for the transaction by copying and using regular read and write operations (e.g. load/store regular instructions 310). Further, the regular cache and other memory resources are utilized instead of the transactional cache. If the read and write operations for the transaction can be performed, a commit transaction instruction 304 is initiated and the state is set to commit (block 434). Thus, the read and write operations to memory are committed (block 415).
On the other hand, if a conflicting transactional write operation is detected then the process may be aborted and the state set to abort (block 436). Thus, the transaction at block 422 is aborted and based on the exception of a conflicting write transaction 438, the process 400 in the software mode, may clean up and retry (block 440) the transactional operation again in the software mode.
In another embodiment of the invention, the previously discussed hardware/software transaction ISA 300 may be utilized to implement locks efficiently. Briefly, when a lock acquire function is invoked, the processor tries to execute the critical section (e.g., the code between the lock acquire and the subsequent lock release) in the hardware mode using transactional memory extensions, and if this fails, the process reverts back to the software mode.
There are three potential reasons why a critical section may fail to complete in the hardware mode. For example, resource exhaustion may occur, in which the transactional cache used to maintain the transactional state overflows. Alternatively, there may be a collision on data. For example, if two threads try to execute their critical section in the hardware mode and attempt to perform conflicting operations on the same data, this may also cause a failure. For instance, one thread may write to a cache line that the other thread has already read. Also, there may be a failure in the transition to the software mode. For example, if a thread grabs a lock in the software mode, all the other threads that were in the middle of the critical section that require that lock will be aborted.
It should be noted that, for any lock, multiple threads can be in the critical section in the hardware mode or a single thread can be holding the lock in the software mode. To enter a lock's critical section in the hardware mode, a thread checks to make sure that a lock is available and enters the critical section without marking it as locked. To enter a lock's critical section in a software mode, a thread checks to make sure that a lock is available and marks it as locked. This will abort any threads that are already in the critical section in the hardware mode and will prevent any new threads from entering the critical section in either the hardware or the software mode.
Looking to FIG. 5, FIG. 5 is a flow diagram illustrating a process 500 to implement locks efficiently utilizing the hardware/software transaction ISA 300, according to one embodiment of the invention. At block 502, a lock is acquired or initiated. At block 504, the policy manager selects a mode. Typically, as previously discussed, the hardware mode is first chosen to try to most efficiently accomplish the transactional memory transactions. The software mode is then reverted to if the hardware mode cannot complete the transaction.
Next, at block 506, the lock is begun and the mode is set to hardware by the Begin Transaction All instruction 302 of the transaction ISA 300. At block 508, the read and write operations are performed for the transaction (e.g. in the transactional cache) using transactional read and write operations (e.g. load/store transactions 308). If the transaction is completed then the lock is released (block 510) and the transaction is committed.
However, if there is an exception due to a conflicting transactional read/write operation 520 then the lock is aborted. A cleanup and retry operation (block 522) is then initiated and the lock is attempted in the software mode. Thus, at block 504 a policy manager selects the software mode.
In this case, the lock is begun in the software mode and the lock's state is set to lock (block 530). Next (block 532), the read and write operations are performed using regular read and write operations (e.g. load and store regular instructions 310). In the software mode, the lock is typically always completed and the lock is then released and the lock state is set to unlock at block 534. This completes the process 500.
In order to obtain further performance benefits the processor may perform conflict resolution. Particularly, when a data conflict is detected, the processor may resolve the conflict and allow one of the transactions to complete. The remaining conflicting transactions may be deferred or aborted dependent upon whether the any of memory locations they have read have been written to by another thread. Furthermore, when an exception 520 (e.g. an orphan transaction exception) has occurred as previously discussed, a record may be made as to whether the transaction was orphaned due to resource exhaustion or due to a data conflict. An exception handler may then be modified to fall back in the software mode only when the resource is exhausted. When only a data conflict has occurred, a modification may be implemented in which the transaction is retried again in the hardware mode, instead of automatically switching to the software mode.
While embodiments of the present invention and its various functional components have been described in particular embodiments, it should be appreciated the embodiments of the present invention can be implemented in hardware, software, firmware, middleware or a combination thereof and utilized in systems, subsystems, components, or sub-components thereof. When implemented in software or firmware, the elements of the present invention are the instructions/code segments to perform the necessary tasks. The program or code segments can be stored in a machine readable medium (e.g. a processor readable medium or a computer program product), or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium or communication link. The machine-readable medium may include any medium that can store or transfer information in a form readable and executable by a machine (e.g. a processor, a computer, etc.). Examples of the machine-readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable programmable ROM (EPROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, bar codes, etc. The code segments may be downloaded via networks such as the Internet, Intranet, etc.
Further, while embodiments of the invention have been described with reference to illustrative embodiments, these descriptions are not intended to be construed in a limiting sense. Various modifications of the illustrative embodiments, as well as other embodiments of the invention, which are apparent to persons skilled in the art to which embodiments of the invention pertain, are deemed to lie within the spirit and scope of the invention.

Claims (32)

1. A method comprising:
selecting, from among modes having a hardware mode and a software mode, the hardware mode to implement transactional memory accesses including detecting an orphan transaction, the orphan transaction including an uncommitted transaction capable of corrupting a memory or a corresponding software program, the hardware mode to utilize a transaction cache of a processor, the software mode to utilize a regular cache of the processor; and
invoking, via the hardware mode utilizing the transaction cache, an orphan transaction exception in lieu of a transaction validate instruction to asynchronously notify a thread of the detection of the orphan transaction, the notification to prevent the orphan transaction from corrupting the memory or the corresponding software program.
2. The method of claim 1, further comprising:
selecting the software mode if an abort instruction is issued in the hardware mode; and
invoking the orphan transaction exception in lieu of the transaction validate instruction via the software mode if the abort instruction is issued in the hardware mode.
3. The method of claim 2, further comprising issuing an abort instruction if a conflicting transaction is detected while operating in the software mode.
4. The method of claim 2, further comprising issuing a commit instruction if a conflicting transaction is not detected.
5. A machine-readable storage medium comprising instructions, which when executed, cause a machine to perform a method, the method comprising:
selecting, from among modes having a hardware mode and a software mode, the hardware mode to implement transactional memory accesses including detecting an orphan transaction, the orphan transaction including an uncommitted transaction capable of corrupting a memory or a corresponding software program, the hardware mode to utilize a transaction cache of a processor, the software mode to utilize a regular cache of the processor; and
invoking, via the hardware mode utilizing the transaction cache, an orphan transaction exception in lieu of a transaction validate instruction to asynchronously notify a thread of the detection of the orphan transaction, the notification to prevent the orphan transaction from corrupting the memory or the corresponding software program.
6. The machine-readable storage medium of claim 5, having further instructions that when executed cause the machine to perform a further method comprising:
selecting the software mode if an abort instruction is issued in the hardware mode; and
invoking the orphan transaction exception in lieu of the transaction validate instruction via the software mode utilizing the regular cache.
7. The machine-readable storage medium of claim 6, having further instructions that when executed cause the machine to perform a further method comprising:
issuing an abort instruction if a conflicting transaction is detected in the software mode.
8. The machine-readable storage medium of claim 6, having further instructions that when executed cause the machine to perform a further method comprising:
issuing a commit instruction if a conflicting transaction is not detected.
9. A computer system comprising:
a processor having a transactional cache and a regular cache, wherein the transactional cache is associated with a hardware mode and the regular cache is associated with a software mode; and
a policy manager to select the hardware mode or the software mode to implement transactional memory accesses including detecting an orphan transaction, the orphan transaction including an uncommitted transaction capable of corrupting a memory or a corresponding software program, the hardware mode to utilize the transaction cache and the software mode to utilize the regular cache, and
wherein the hardware mode utilizing the transaction cache to invoke an orphan transaction exception in lieu of a transaction validate instruction to asynchronously notify a thread of the detection of the orphan transaction, and wherein the notification to prevent the orphan transaction from corrupting the memory or the corresponding software program.
10. The computer system of claim 9, wherein, if an abort instruction is issued for the hardware mode, the policy manager to select the software mode utilizing the regular cache to invoke the orphan transaction exception in lieu of the transaction validate instruction.
11. The computer system of claim 10, wherein, operating in the software mode, if a conflicting transaction is detected, an abort instruction is issued.
12. The computer system of claim 10, wherein, if a conflicting transaction is not detected, a commit instruction is issued.
13. A processor comprising:
a transactional cache and a regular cache, wherein the transactional cache is associated with a hardware mode and the regular cache is associated with a software mode; and
a policy manager to select the hardware mode or the software mode to implement transactional memory accesses and to detect an orphan transaction, the orphan transaction including an uncommitted transaction capable of corrupting a memory or a corresponding software program, the hardware mode to utilize the transaction cache and the software mode to utilize the regular cache,
wherein the hardware mode utilizing the transactional cache to invoke an orphan transaction exception in lieu of a transaction validate instruction to asynchronously notify a thread of the detection of the orphan transaction, and wherein the notification to prevent the orphan transaction from corrupting the memory or the corresponding software program.
14. The processor of claim 13, wherein, if an abort instruction is issued for the hardware mode, the policy manager to select the software mode utilizing the regular cache to invoke the orphan transaction exception in lieu of the transaction validate instruction.
15. The processor of claim 14, wherein, operating in the software mode, if a conflicting transaction is detected, an abort instruction is issued.
16. The processor of claim 14, wherein, if a conflicting transaction is not detected, a commit instruction is issued.
17. A method comprising:
selecting, from among modes having a hardware mode and a software mode, the hardware mode before selecting the software mode to implement transactional memory accesses including detecting initiating of a lock acquire function, wherein the lock acquire function is initiated to acquire a lock in a lock-based programming system, wherein the hardware mode to utilize a transaction cache of a processor, and wherein the software mode to utilize a regular cache of the processor;
entering by a thread a critical section without marking it as locked to abort any other threads already in the hardware mode; and
executing, via the hardware mode utilizing the transaction cache, the critical section that refers to a programming code section being executed between an acquisition of the lock and a subsequent release of the lock.
18. The method of claim 17, further comprising automatically triggering the software mode utilizing the regular cache resident to execute the critical section if the hardware mode fails and an abort instruction is issued.
19. The method of claim 17, further comprising:
verifying by the thread if the lock is available;
preventing by the thread any new threads from entering the critical section in the hardware mode.
20. The method of claim 17, further comprising:
verifying by a thread if the lock is available; and
entering the critical section by marking it as locked to prevent any new threads from entering the critical section in the software mode.
21. A machine-readable storage medium having instructions, which when executed, cause a machine to perform a method, the method comprising:
selecting, from among modes having a hardware mode and a software mode, the hardware mode before selecting the software mode to implement transactional memory accesses including detecting initiating of a lock acquire function, wherein the lock acquire function is initiated to acquire a lock in a lock-based programming system, wherein the hardware mode to utilize a transaction cache of a processor, and wherein the software mode to utilize a regular cache of the processor;
entering by a thread a critical section without marking it as locked to abort any other threads already in the hardware mode; and
executing, via the hardware mode utilizing the transaction cache the critical section that refers to a programming code section being executed between an acquisition of the lock and a subsequent release of the lock.
22. The machine-readable storage medium of claim 21, having further instructions that when executed cause the machine to perform a further method comprising:
automatically triggering the software mode utilizing the regular cache to execute the critical section if the hardware mode fails and an abort instruction is issued.
23. The machine-readable storage medium of claim 21, having further instructions that when executed cause the machine to perform a further method comprising:
verifying by the thread if the lock is available when entering the critical section of the lock in the hardware mode; and
preventing by the thread any new threads from entering the critical section in the hardware mode.
24. The machine-readable storage medium of claim 21, having further instructions that when executed cause the machine to perform a further method comprising:
verifying by a thread if the lock is available when entering the critical section of the lock in the software mode; and
entering the critical section marking it as locked to prevent any new threads from entering the critical section in the software mode.
25. A computer system comprising:
a processor including a transactional cache and a regular cache;
a policy manager to select, from among modes having a hardware mode and a software mode, the hardware mode before selecting the software mode to implement transactional memory accesses and to detect initiating of a lock acquire function, wherein the lock acquire function is initiated to acquire a lock in a lock-based programming system, wherein the hardware mode to utilize the transaction cache and the software mode to utilize the regular cache, and
a thread to enter a critical section without marking it as locked to abort any other threads already in the hardware mode,
wherein the hardware mode utilizing the transaction cache to execute the critical section that refers to a programming code section being executed between an acquisition of the lock and a subsequent release of the lock.
26. The computer system of claim 25, wherein the policy manager is further to automatically trigger the software mode utilizing the regular cache to execute the critical section if the hardware mode fails and an abort instruction is issued.
27. The computer system of claim 25, further comprising the thread to:
verify if the lock is available when entering the critical section of the lock in the hardware mode, and
prevent any new threads from entering the critical section in the hardware mode.
28. The computer system of claim 25, further comprising a thread to:
verify if the lock is available when entering the critical section of the lock in the software mode, and
enter the critical section marking it as locked to prevent any new threads from entering the critical section in the software mode.
29. A processor comprising:
a transactional cache and a regular cache, wherein the transactional cache is associated with a hardware mode and the regular cache is associated with a software mode;
a policy manager to select, from among modes having a hardware mode and a software mode, the hardware mode before selecting the software mode to implement transactional memory accesses and to detect initiating of a lock acquire function, wherein the lock acquire function is initiated to acquire a lock in a lock-based programming system, wherein the hardware mode to utilize the transaction cache and the software mode to utilize the regular cache; and
a thread to enter a critical section without marking it as locked to abort any other threads already in the hardware mode,
wherein the hardware mode utilizing the transaction cache to execute the critical section that refers to a programming code section being executed between an acquisition of the lock and a subsequent release of the lock.
30. The processor of claim 29, wherein the policy manager is further to automatically trigger the software mode utilizing the regular cache to execute the critical section if the hardware mode fails and an abort instruction is issued.
31. The processor of claim 29, further comprising the thread to:
verify if the lock is available when entering the critical section of the lock in the hardware mode, and
prevent any new threads from entering the critical section in the hardware mode.
32. The processor of claim 29, further comprising a thread to:
verify if the lock is available when entering the critical section of the lock in the software mode, and
enter the critical section marking it as locked to prevent any new threads from entering the critical section in the software mode.
US10/956,179 2004-09-30 2004-09-30 Hybrid hardware and software implementation of transactional memory access Active 2025-04-14 US7856537B2 (en)

Priority Applications (11)

Application Number Priority Date Filing Date Title
US10/956,179 US7856537B2 (en) 2004-09-30 2004-09-30 Hybrid hardware and software implementation of transactional memory access
PCT/US2005/033917 WO2006039174A1 (en) 2004-09-30 2005-09-21 Hybrid hardware and software implementation of transactional memory access
JP2007533617A JP4774056B2 (en) 2004-09-30 2005-09-21 Method and apparatus for implementing hybrid hardware and software for transactional memory access
DE112005002402.4T DE112005002402B4 (en) 2004-09-30 2005-09-21 Hybrid hardware / software implementation of transactional memory access
CN201010144199.7A CN101807169B (en) 2004-09-30 2005-09-30 Hybrid hardware and software implementation of transactional memory access
CN2005101078095A CN1755635B (en) 2004-09-30 2005-09-30 Hybrid hardware and software implementation of transactional memory access
US12/943,848 US8661206B2 (en) 2004-09-30 2010-11-10 Hybrid hardware and software implementation of transactional memory access
US13/843,890 US9529715B2 (en) 2004-09-30 2013-03-15 Hybrid hardware and software implementation of transactional memory access
US15/299,452 US10102123B2 (en) 2004-09-30 2016-10-20 Hybrid hardware and software implementation of transactional memory access
US15/477,055 US10268579B2 (en) 2004-09-30 2017-04-01 Hybrid hardware and software implementation of transactional memory access
US15/477,052 US10180903B2 (en) 2004-09-30 2017-04-01 Hybrid hardware and software implementation of transactional memory access

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/956,179 US7856537B2 (en) 2004-09-30 2004-09-30 Hybrid hardware and software implementation of transactional memory access

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/943,848 Continuation US8661206B2 (en) 2004-09-30 2010-11-10 Hybrid hardware and software implementation of transactional memory access

Publications (2)

Publication Number Publication Date
US20060085591A1 US20060085591A1 (en) 2006-04-20
US7856537B2 true US7856537B2 (en) 2010-12-21

Family

ID=35519767

Family Applications (6)

Application Number Title Priority Date Filing Date
US10/956,179 Active 2025-04-14 US7856537B2 (en) 2004-09-30 2004-09-30 Hybrid hardware and software implementation of transactional memory access
US12/943,848 Expired - Fee Related US8661206B2 (en) 2004-09-30 2010-11-10 Hybrid hardware and software implementation of transactional memory access
US13/843,890 Expired - Lifetime US9529715B2 (en) 2004-09-30 2013-03-15 Hybrid hardware and software implementation of transactional memory access
US15/299,452 Expired - Lifetime US10102123B2 (en) 2004-09-30 2016-10-20 Hybrid hardware and software implementation of transactional memory access
US15/477,055 Expired - Lifetime US10268579B2 (en) 2004-09-30 2017-04-01 Hybrid hardware and software implementation of transactional memory access
US15/477,052 Expired - Lifetime US10180903B2 (en) 2004-09-30 2017-04-01 Hybrid hardware and software implementation of transactional memory access

Family Applications After (5)

Application Number Title Priority Date Filing Date
US12/943,848 Expired - Fee Related US8661206B2 (en) 2004-09-30 2010-11-10 Hybrid hardware and software implementation of transactional memory access
US13/843,890 Expired - Lifetime US9529715B2 (en) 2004-09-30 2013-03-15 Hybrid hardware and software implementation of transactional memory access
US15/299,452 Expired - Lifetime US10102123B2 (en) 2004-09-30 2016-10-20 Hybrid hardware and software implementation of transactional memory access
US15/477,055 Expired - Lifetime US10268579B2 (en) 2004-09-30 2017-04-01 Hybrid hardware and software implementation of transactional memory access
US15/477,052 Expired - Lifetime US10180903B2 (en) 2004-09-30 2017-04-01 Hybrid hardware and software implementation of transactional memory access

Country Status (5)

Country Link
US (6) US7856537B2 (en)
JP (1) JP4774056B2 (en)
CN (2) CN1755635B (en)
DE (1) DE112005002402B4 (en)
WO (1) WO2006039174A1 (en)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060161740A1 (en) * 2004-12-29 2006-07-20 Sailesh Kottapalli Transaction based shared data operations in a multiprocessor environment
US20090282386A1 (en) * 2008-05-12 2009-11-12 Moir Mark S System and Method for Utilizing Available Best Effort Hardware Mechanisms for Supporting Transactional Memory
US20100131953A1 (en) * 2008-11-26 2010-05-27 David Dice Method and System for Hardware Feedback in Transactional Memory
US20100138836A1 (en) * 2008-12-03 2010-06-03 David Dice System and Method for Reducing Serialization in Transactional Memory Using Gang Release of Blocked Threads
US20100332807A1 (en) * 2009-06-26 2010-12-30 Microsoft Corporation Performing escape actions in transactions
US20100332768A1 (en) * 2009-06-26 2010-12-30 Microsoft Corporation Flexible read- and write-monitored and buffered memory blocks
US20110145553A1 (en) * 2009-12-15 2011-06-16 Microsoft Corporation Accelerating parallel transactions using cache resident transactions
US20110145802A1 (en) * 2009-12-15 2011-06-16 Microsoft Corporation Accelerating unbounded memory transactions using nested cache resident transactions
US20140007133A1 (en) * 2012-06-29 2014-01-02 Nicholas J. Adams System and method to provide single thread access to a specific memory region
US8688951B2 (en) 2009-06-26 2014-04-01 Microsoft Corporation Operating system virtual memory management for hardware transactional memory
US20140136783A1 (en) * 2004-09-30 2014-05-15 Sanjeev Kumar Hybrid hardware and software implementation of transactional memory access
US8812796B2 (en) 2009-06-26 2014-08-19 Microsoft Corporation Private memory regions and coherence optimizations
US20150026688A1 (en) * 2013-07-16 2015-01-22 Oracle International Corporation Systems and Methods for Adaptive Integration of Hardware and Software Lock Elision Techniques
US9043363B2 (en) * 2011-06-03 2015-05-26 Oracle International Corporation System and method for performing memory management using hardware transactions
USRE45632E1 (en) * 2005-01-03 2015-07-28 O'shantel Software L.L.C. Memory-controller-embedded apparatus and procedure for achieving system-directed checkpointing without operating-system kernel support
US9092253B2 (en) 2009-12-15 2015-07-28 Microsoft Technology Licensing, Llc Instrumentation of hardware assisted transactional memory system
US20160188342A1 (en) * 2014-12-24 2016-06-30 Elmoustapha Ould-Ahmed-Vall Systems, apparatuses, and methods for data speculation execution
US9658880B2 (en) 2009-12-15 2017-05-23 Microsoft Technology Licensing, Llc Efficient garbage collection and exception handling in a hardware accelerated transactional memory system
US10061583B2 (en) 2014-12-24 2018-08-28 Intel Corporation Systems, apparatuses, and methods for data speculation execution
US10061589B2 (en) 2014-12-24 2018-08-28 Intel Corporation Systems, apparatuses, and methods for data speculation execution
US10303525B2 (en) 2014-12-24 2019-05-28 Intel Corporation Systems, apparatuses, and methods for data speculation execution
US10387156B2 (en) 2014-12-24 2019-08-20 Intel Corporation Systems, apparatuses, and methods for data speculation execution
US10942744B2 (en) 2014-12-24 2021-03-09 Intel Corporation Systems, apparatuses, and methods for data speculation execution

Families Citing this family (103)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7921407B2 (en) * 2004-08-10 2011-04-05 Oracle America, Inc. System and method for supporting multiple alternative methods for executing transactions
US7685365B2 (en) * 2004-09-30 2010-03-23 Intel Corporation Transactional memory execution utilizing virtual memory
US7630991B2 (en) * 2005-10-27 2009-12-08 Microsoft Corporation Compiling join patterns using software transactional memories
US8813052B2 (en) 2005-12-07 2014-08-19 Microsoft Corporation Cache metadata for implementing bounded transactional memory
US8225297B2 (en) 2005-12-07 2012-07-17 Microsoft Corporation Cache metadata identifiers for isolation and sharing
US8001538B2 (en) 2005-12-07 2011-08-16 Microsoft Corporation Software accessible cache metadata
US7730286B2 (en) * 2005-12-30 2010-06-01 Intel Corporation Software assisted nested hardware transactions
US8683143B2 (en) * 2005-12-30 2014-03-25 Intel Corporation Unbounded transactional memory systems
US20070186056A1 (en) * 2006-02-07 2007-08-09 Bratin Saha Hardware acceleration for a software transactional memory system
US8898652B2 (en) * 2006-03-23 2014-11-25 Microsoft Corporation Cache metadata for accelerating software transactional memory
US8180967B2 (en) * 2006-03-30 2012-05-15 Intel Corporation Transactional memory virtualization
US8180977B2 (en) * 2006-03-30 2012-05-15 Intel Corporation Transactional memory in out-of-order processors
US8108627B2 (en) * 2006-03-31 2012-01-31 Intel Corporation Array comparison and swap operations
US7792805B2 (en) * 2006-05-30 2010-09-07 Oracle America, Inc. Fine-locked transactional memory
US20080005504A1 (en) * 2006-06-30 2008-01-03 Jesse Barnes Global overflow method for virtualized transactional memory
US20080040524A1 (en) * 2006-08-14 2008-02-14 Zimmer Vincent J System management mode using transactional memory
US9798590B2 (en) * 2006-09-07 2017-10-24 Intel Corporation Post-retire scheme for tracking tentative accesses during transactional execution
US8924653B2 (en) * 2006-10-31 2014-12-30 Hewlett-Packard Development Company, L.P. Transactional cache memory system
US8806495B2 (en) * 2006-11-20 2014-08-12 Microsoft Corp. Lightweight transactional memory for data parallel programming
US8522223B2 (en) * 2006-11-22 2013-08-27 Intel Corporation Automatic function call in multithreaded application
US7802136B2 (en) 2006-12-28 2010-09-21 Intel Corporation Compiler technique for efficient register checkpointing to support transaction roll-back
US8060482B2 (en) * 2006-12-28 2011-11-15 Intel Corporation Efficient and consistent software transactional memory
US7689733B2 (en) * 2007-03-09 2010-03-30 Microsoft Corporation Method and apparatus for policy-based direct memory access control
US8185698B2 (en) * 2007-04-09 2012-05-22 Bratin Saha Hardware acceleration of a write-buffering software transactional memory
US7908255B2 (en) * 2007-04-11 2011-03-15 Microsoft Corporation Transactional memory using buffered writes and enforced serialization order
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
US8095750B2 (en) * 2007-05-14 2012-01-10 International Business Machines Corporation Transactional memory system with fast processing of common conflicts
US8688920B2 (en) * 2007-05-14 2014-04-01 International Business Machines Corporation Computing system with guest code support of transactional memory
US8095741B2 (en) * 2007-05-14 2012-01-10 International Business Machines Corporation Transactional memory computing system with support for chained transactions
US7644238B2 (en) 2007-06-01 2010-01-05 Microsoft Corporation Timestamp based transactional memory
US8458724B2 (en) 2007-06-15 2013-06-04 Microsoft Corporation Automatic mutual exclusion
US9043553B2 (en) * 2007-06-27 2015-05-26 Microsoft Technology Licensing, Llc Leveraging transactional memory hardware to accelerate virtualization and emulation
US9280397B2 (en) * 2007-06-27 2016-03-08 Intel Corporation Using buffered stores or monitoring to filter redundant transactional accesses and mechanisms for mapping data to buffered metadata
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
US8140773B2 (en) 2007-06-27 2012-03-20 Bratin Saha Using ephemeral stores for fine-grained conflict detection in a hardware accelerated STM
US8612643B2 (en) 2007-06-30 2013-12-17 Microsoft Corporation Interfaces for digital media processing
CN101452400B (en) * 2007-11-29 2011-12-28 国际商业机器公司 Method and system for processing transaction buffer overflow in multiprocessor system
US8140497B2 (en) * 2007-12-31 2012-03-20 Oracle America, Inc. System and method for implementing nonblocking zero-indirection transactional memory
US7966459B2 (en) * 2007-12-31 2011-06-21 Oracle America, Inc. System and method for supporting phased transactional memory modes
EP2274676A1 (en) 2008-01-31 2011-01-19 Oracle International Corporation System and method for transactional cache
CN101587447B (en) * 2008-05-23 2013-03-27 国际商业机器公司 System supporting transaction storage and prediction-based transaction execution method
US9047139B2 (en) * 2008-06-27 2015-06-02 Microsoft Technology Licensing, Llc Primitives for software transactional memory
US8166481B2 (en) * 2008-10-20 2012-04-24 Microsoft Corporation Transaction processing in transactional memory
US8627017B2 (en) * 2008-12-30 2014-01-07 Intel Corporation Read and write monitoring attributes in transactional memory (TM) systems
US8312219B2 (en) * 2009-03-02 2012-11-13 International Business Machines Corporation Hybrid caching techniques and garbage collection using hybrid caching techniques
US8161247B2 (en) * 2009-06-26 2012-04-17 Microsoft Corporation Wait loss synchronization
US8370577B2 (en) 2009-06-26 2013-02-05 Microsoft Corporation Metaphysically addressed cache metadata
US8356166B2 (en) * 2009-06-26 2013-01-15 Microsoft Corporation Minimizing code duplication in an unbounded transactional memory system by using mode agnostic transactional read and write barriers
US8229907B2 (en) * 2009-06-30 2012-07-24 Microsoft Corporation Hardware accelerated transactional memory system with open nested transactions
US8566524B2 (en) 2009-08-31 2013-10-22 International Business Machines Corporation Transactional memory system with efficient cache support
US9639392B2 (en) * 2013-12-17 2017-05-02 Intel Corporation Unbounded transactional memory with forward progress guarantees using a hardware global lock
US20110113409A1 (en) * 2009-11-10 2011-05-12 Rodrick Evans Symbol capabilities support within elf
US8739164B2 (en) * 2010-02-24 2014-05-27 Advanced Micro Devices, Inc. Automatic suspend atomic hardware transactional memory in response to detecting an implicit suspend condition and resume thereof
US8464261B2 (en) 2010-03-31 2013-06-11 Oracle International Corporation System and method for executing a transaction using parallel co-transactions
US8402227B2 (en) 2010-03-31 2013-03-19 Oracle International Corporation System and method for committing results of a software transaction using a hardware transaction
US8214560B2 (en) 2010-04-20 2012-07-03 International Business Machines Corporation Communications support in a transactional memory
US9411634B2 (en) 2010-06-21 2016-08-09 Microsoft Technology Licensing, Llc Action framework in software transactional memory
US8719515B2 (en) 2010-06-21 2014-05-06 Microsoft Corporation Composition of locks in software transactional memory
US9110691B2 (en) * 2010-11-16 2015-08-18 Advanced Micro Devices, Inc. Compiler support technique for hardware transactional memory systems
US9870384B2 (en) * 2012-03-30 2018-01-16 International Business Machines Corporation Database system transaction management
US20130332778A1 (en) * 2012-06-07 2013-12-12 Vmware, Inc. Performance-imbalance-monitoring processor features
US9448796B2 (en) 2012-06-15 2016-09-20 International Business Machines Corporation Restricted instructions in transactional execution
US9223687B2 (en) 2012-06-15 2015-12-29 International Business Machines Corporation Determining the logical address of a transaction abort
US9384004B2 (en) 2012-06-15 2016-07-05 International Business Machines Corporation Randomized testing within transactional execution
US9772854B2 (en) 2012-06-15 2017-09-26 International Business Machines Corporation Selectively controlling instruction execution in transactional processing
US8966324B2 (en) 2012-06-15 2015-02-24 International Business Machines Corporation Transactional execution branch indications
US8688661B2 (en) * 2012-06-15 2014-04-01 International Business Machines Corporation Transactional processing
US9740549B2 (en) 2012-06-15 2017-08-22 International Business Machines Corporation Facilitating transaction completion subsequent to repeated aborts of the transaction
US9367323B2 (en) 2012-06-15 2016-06-14 International Business Machines Corporation Processor assist facility
US8880959B2 (en) 2012-06-15 2014-11-04 International Business Machines Corporation Transaction diagnostic block
US9262320B2 (en) * 2012-06-15 2016-02-16 International Business Machines Corporation Tracking transactional execution footprint
US9348642B2 (en) 2012-06-15 2016-05-24 International Business Machines Corporation Transaction begin/end instructions
US9336046B2 (en) 2012-06-15 2016-05-10 International Business Machines Corporation Transaction abort processing
US9298469B2 (en) 2012-06-15 2016-03-29 International Business Machines Corporation Management of multiple nested transactions
US10437602B2 (en) 2012-06-15 2019-10-08 International Business Machines Corporation Program interruption filtering in transactional execution
US9298631B2 (en) 2012-06-15 2016-03-29 International Business Machines Corporation Managing transactional and non-transactional store observability
US9361115B2 (en) 2012-06-15 2016-06-07 International Business Machines Corporation Saving/restoring selected registers in transactional processing
US9436477B2 (en) 2012-06-15 2016-09-06 International Business Machines Corporation Transaction abort instruction
US9311101B2 (en) 2012-06-15 2016-04-12 International Business Machines Corporation Intra-instructional transaction abort handling
US20130339680A1 (en) 2012-06-15 2013-12-19 International Business Machines Corporation Nontransactional store instruction
US9442737B2 (en) 2012-06-15 2016-09-13 International Business Machines Corporation Restricting processing within a processor to facilitate transaction completion
US9015419B2 (en) 2012-06-15 2015-04-21 International Business Machines Corporation Avoiding aborts due to associativity conflicts in a transactional environment
US9317460B2 (en) 2012-06-15 2016-04-19 International Business Machines Corporation Program event recording within a transactional environment
US8682877B2 (en) 2012-06-15 2014-03-25 International Business Machines Corporation Constrained transaction execution
US9058282B2 (en) 2012-12-31 2015-06-16 Intel Corporation Dynamic cache write policy
US9032152B2 (en) 2013-03-22 2015-05-12 Applied Micro Circuits Corporation Cache miss detection filter
US9361152B2 (en) * 2013-07-15 2016-06-07 Intel Corporation Transactional memory management techniques
US9558229B2 (en) * 2013-11-26 2017-01-31 Sap Se Transaction private log buffering for high performance of transaction processing
JP6244916B2 (en) 2014-01-06 2017-12-13 富士通株式会社 Arithmetic processing apparatus, control method for arithmetic processing apparatus, and information processing apparatus
US9471371B2 (en) * 2014-02-27 2016-10-18 International Business Machines Corporation Dynamic prediction of concurrent hardware transactions resource requirements and allocation
US9971627B2 (en) 2014-03-26 2018-05-15 Intel Corporation Enabling maximum concurrency in a hybrid transactional memory system
JP6023765B2 (en) * 2014-09-01 2016-11-09 インテル・コーポレーション Unlimited transactional memory (UTM) system optimization
US10180921B2 (en) * 2015-06-26 2019-01-15 International Business Machines Corporation Non-interfering transactions
US10445271B2 (en) * 2016-01-04 2019-10-15 Intel Corporation Multi-core communication acceleration using hardware queue device
JP6318440B2 (en) * 2016-10-07 2018-05-09 インテル・コーポレーション Unlimited transactional memory (UTM) system optimization
US10929033B2 (en) 2018-04-25 2021-02-23 Micron Technology, Inc. Allocating variable media types of memory devices in a memory system
US11010309B2 (en) * 2018-05-18 2021-05-18 Intel Corporation Computer system and method for executing one or more software applications, host computer device and method for a host computer device, memory device and method for a memory device and non-transitory computer readable medium
US10754776B2 (en) 2018-07-30 2020-08-25 International Business Machines Corporation Cache balance when using hardware transactional memory
US20230342157A1 (en) * 2021-01-11 2023-10-26 Next Silicon Ltd Optimizing reconfigurable hardware using data sampling
US11741007B2 (en) * 2021-01-15 2023-08-29 Neo4J Sweden Ab Memory guards for continuous load-adaptive processing of transactions in databases
CN113778330B (en) * 2021-08-05 2023-04-25 无锡融卡科技有限公司 Transaction processing method based on Flash memory

Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5347428A (en) * 1992-12-03 1994-09-13 Irvine Sensors Corporation Module comprising IC memory stack dedicated to and structurally combined with an IC microprocessor chip
US5428761A (en) * 1992-03-12 1995-06-27 Digital Equipment Corporation System for achieving atomic non-sequential multi-word operations in shared memory
US20020038407A1 (en) * 1999-01-05 2002-03-28 Farnaz Mounes-Toussi Circuit arrangement and method with state-based transaction scheduling
US20020073071A1 (en) * 1999-02-26 2002-06-13 Fong Pong Transactional memory for distributed shared memory multi-processor computer systems
JP2003167765A (en) 2001-11-30 2003-06-13 Canon Inc Information processor and processing method
US20040073909A1 (en) * 2002-10-10 2004-04-15 International Business Machines Corporation High speed promotion mechanism suitable for lock acquisition in a multiprocessor data processing system
EP1416387A2 (en) 2002-10-31 2004-05-06 Lg Electronics Inc. System and method for maintaining transaction cache consistency in mobile computing environment
US20050060559A1 (en) * 2003-09-12 2005-03-17 Mckenney Paul E. Utilizing hardware transactional approach to execute code after initially utilizing software locking by employing pseudo-transactions
US20050086446A1 (en) * 2003-10-04 2005-04-21 Mckenney Paul E. Utilizing software locking approach to execute code upon failure of hardware transactional approach
US20070156994A1 (en) * 2005-12-30 2007-07-05 Akkary Haitham H Unbounded transactional memory systems
US20070282838A1 (en) * 2006-05-30 2007-12-06 Sun Microsystems, Inc. Fine-locked transactional memory
US20090172306A1 (en) * 2007-12-31 2009-07-02 Nussbaum Daniel S System and Method for Supporting Phased Transactional Memory Modes
US20090172299A1 (en) * 2007-12-31 2009-07-02 Goodman James R System and Method for Implementing Hybrid Single-Compare-Single-Store Operations
US20090177847A1 (en) * 2008-01-09 2009-07-09 International Business Machines Corporation System and method for handling overflow in hardware transactional memory with locks
US20090210457A1 (en) * 2008-02-19 2009-08-20 Microsoft Corporation Transactional memory with dynamic separation

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7395274B2 (en) * 2002-07-16 2008-07-01 Sun Microsystems, Inc. Space- and time-adaptive nonblocking algorithms
US6976131B2 (en) 2002-08-23 2005-12-13 Intel Corporation Method and apparatus for shared cache coherency for a chip multiprocessor or multiprocessor system
US20040163082A1 (en) * 2003-02-13 2004-08-19 Marc Tremblay Commit instruction to support transactional program execution
US7856537B2 (en) * 2004-09-30 2010-12-21 Intel Corporation Hybrid hardware and software implementation of transactional memory access

Patent Citations (16)

* 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
US5347428A (en) * 1992-12-03 1994-09-13 Irvine Sensors Corporation Module comprising IC memory stack dedicated to and structurally combined with an IC microprocessor chip
US20020038407A1 (en) * 1999-01-05 2002-03-28 Farnaz Mounes-Toussi Circuit arrangement and method with state-based transaction scheduling
US20020073071A1 (en) * 1999-02-26 2002-06-13 Fong Pong Transactional memory for distributed shared memory multi-processor computer systems
JP2003167765A (en) 2001-11-30 2003-06-13 Canon Inc Information processor and processing method
US20040073909A1 (en) * 2002-10-10 2004-04-15 International Business Machines Corporation High speed promotion mechanism suitable for lock acquisition in a multiprocessor data processing system
EP1416387A2 (en) 2002-10-31 2004-05-06 Lg Electronics Inc. System and method for maintaining transaction cache consistency in mobile computing environment
US7587615B2 (en) * 2003-09-12 2009-09-08 International Business Machines Corporation Utilizing hardware transactional approach to execute code after initially utilizing software locking by employing pseudo-transactions
US20050060559A1 (en) * 2003-09-12 2005-03-17 Mckenney Paul E. Utilizing hardware transactional approach to execute code after initially utilizing software locking by employing pseudo-transactions
US20050086446A1 (en) * 2003-10-04 2005-04-21 Mckenney Paul E. Utilizing software locking approach to execute code upon failure of hardware transactional approach
US20070156994A1 (en) * 2005-12-30 2007-07-05 Akkary Haitham H Unbounded transactional memory systems
US20070282838A1 (en) * 2006-05-30 2007-12-06 Sun Microsystems, Inc. Fine-locked transactional memory
US20090172306A1 (en) * 2007-12-31 2009-07-02 Nussbaum Daniel S System and Method for Supporting Phased Transactional Memory Modes
US20090172299A1 (en) * 2007-12-31 2009-07-02 Goodman James R System and Method for Implementing Hybrid Single-Compare-Single-Store Operations
US20090177847A1 (en) * 2008-01-09 2009-07-09 International Business Machines Corporation System and method for handling overflow in hardware transactional memory with locks
US20090210457A1 (en) * 2008-02-19 2009-08-20 Microsoft Corporation Transactional memory with dynamic separation

Non-Patent Citations (11)

* Cited by examiner, † Cited by third party
Title
CN PTO, "Non-Final Office Action", Chinese Patent Application No. 200510107809.5, Mailed Jun. 5, 2009, whole document.
CN PTO, "Notice of Allowance", Chinese Patent Application No. 200510107809.5, Mailed Jan. 26, 2010, whole document.
German Patent Application 11 2005 002 402.4-53 Office Action dated Oct. 9, 2008.
Herlihy, M. "Transactional Memory: Architectural Support for Lock-Free Data Structures", Proceedings of the Twentieth Annual International Symposium on Computer Architecture (1993).
Herlihy, M., "Software Transactional Memory for Dynamic-Sized Data Structures", Principals of Distributed Computing, Sun Microsystems, ISBN 1.58113-661-7/03/0006 (Jul. 2003). Boston, MA.
Japanese Office Action mailed May 11, 2010 for Japanese Application No. 2007/533617 Summary and Translation Only.
Martinez, J., "Speculative Synchronization: Applying Thread-Level Speculation to Explicitly Parallel Applications" ASPLOS X, ISBN 1-58113-574-2/02/00100 (Oct. 2002), ACM, San Jose, CA.
Patent Cooperation Treaty, "International Preliminary Report on Patentability", International Application No. PCT/US2005/033917; Mailed Apr. 3, 2007, Whole Document.
Patent Cooperation Treaty, "International Search Report", International Application No. PCT/US2005/033917; Mailed Jan. 1, 2004, Whole Document.
Rajwar, R., "Transactional Execution Toward Reliable, High-Performance Multithreading" IEEE Micro, pp. 117-125, IEE computer society (Nov. 2003).
Rajwar, R., "Transactional Lock-Free Execution of Lock-Based Programs", ASPLOS X, ISBN 1-58113-574-2/02/00100 (Oct. 2002), ACM, San Jose, CA.

Cited By (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10102123B2 (en) 2004-09-30 2018-10-16 Intel Corporation Hybrid hardware and software implementation of transactional memory access
US9529715B2 (en) * 2004-09-30 2016-12-27 Intel Corporation Hybrid hardware and software implementation of transactional memory access
US20140136783A1 (en) * 2004-09-30 2014-05-15 Sanjeev Kumar Hybrid hardware and software implementation of transactional memory access
US10268579B2 (en) 2004-09-30 2019-04-23 Intel Corporation Hybrid hardware and software implementation of transactional memory access
US10180903B2 (en) 2004-09-30 2019-01-15 Intel Corporation Hybrid hardware and software implementation of transactional memory access
US20110055493A1 (en) * 2004-12-29 2011-03-03 Sailesh Kottapalli Transaction based shared data operations in a multiprocessor environment
US7984248B2 (en) 2004-12-29 2011-07-19 Intel Corporation Transaction based shared data operations in a multiprocessor environment
US8176266B2 (en) 2004-12-29 2012-05-08 Intel Corporation Transaction based shared data operations in a multiprocessor environment
US8458412B2 (en) 2004-12-29 2013-06-04 Intel Corporation Transaction based shared data operations in a multiprocessor environment
US20060161740A1 (en) * 2004-12-29 2006-07-20 Sailesh Kottapalli Transaction based shared data operations in a multiprocessor environment
USRE45632E1 (en) * 2005-01-03 2015-07-28 O'shantel Software L.L.C. Memory-controller-embedded apparatus and procedure for achieving system-directed checkpointing without operating-system kernel support
US20090282386A1 (en) * 2008-05-12 2009-11-12 Moir Mark S System and Method for Utilizing Available Best Effort Hardware Mechanisms for Supporting Transactional Memory
US8533663B2 (en) * 2008-05-12 2013-09-10 Oracle America, Inc. System and method for utilizing available best effort hardware mechanisms for supporting transactional memory
US20100131953A1 (en) * 2008-11-26 2010-05-27 David Dice Method and System for Hardware Feedback in Transactional Memory
US8776063B2 (en) * 2008-11-26 2014-07-08 Oracle America, Inc. Method and system for hardware feedback in transactional memory
US8789057B2 (en) * 2008-12-03 2014-07-22 Oracle America, Inc. System and method for reducing serialization in transactional memory using gang release of blocked threads
US20100138836A1 (en) * 2008-12-03 2010-06-03 David Dice System and Method for Reducing Serialization in Transactional Memory Using Gang Release of Blocked Threads
US8688951B2 (en) 2009-06-26 2014-04-01 Microsoft Corporation Operating system virtual memory management for hardware transactional memory
US9767027B2 (en) 2009-06-26 2017-09-19 Microsoft Technology Licensing, Llc Private memory regions and coherency optimization by controlling snoop traffic volume in multi-level cache hierarchy
US20100332768A1 (en) * 2009-06-26 2010-12-30 Microsoft Corporation Flexible read- and write-monitored and buffered memory blocks
US8489864B2 (en) 2009-06-26 2013-07-16 Microsoft Corporation Performing escape actions in transactions
US8812796B2 (en) 2009-06-26 2014-08-19 Microsoft Corporation Private memory regions and coherence optimizations
US20100332807A1 (en) * 2009-06-26 2010-12-30 Microsoft Corporation Performing escape actions in transactions
US20110145802A1 (en) * 2009-12-15 2011-06-16 Microsoft Corporation Accelerating unbounded memory transactions using nested cache resident transactions
US9092253B2 (en) 2009-12-15 2015-07-28 Microsoft Technology Licensing, Llc Instrumentation of hardware assisted transactional memory system
US20110145553A1 (en) * 2009-12-15 2011-06-16 Microsoft Corporation Accelerating parallel transactions using cache resident transactions
US8533440B2 (en) * 2009-12-15 2013-09-10 Microsoft Corporation Accelerating parallel transactions using cache resident transactions
US9658880B2 (en) 2009-12-15 2017-05-23 Microsoft Technology Licensing, Llc Efficient garbage collection and exception handling in a hardware accelerated transactional memory system
US8539465B2 (en) 2009-12-15 2013-09-17 Microsoft Corporation Accelerating unbounded memory transactions using nested cache resident transactions
US9043363B2 (en) * 2011-06-03 2015-05-26 Oracle International Corporation System and method for performing memory management using hardware transactions
US10095557B2 (en) * 2012-06-29 2018-10-09 Intel Corporation System and method to provide single thread access to a specific memory region
US20140007133A1 (en) * 2012-06-29 2014-01-02 Nicholas J. Adams System and method to provide single thread access to a specific memory region
US20150026688A1 (en) * 2013-07-16 2015-01-22 Oracle International Corporation Systems and Methods for Adaptive Integration of Hardware and Software Lock Elision Techniques
US9619281B2 (en) 2013-07-16 2017-04-11 Oracle International Corporation Systems and methods for adaptive integration of hardware and software lock elision techniques
US9183043B2 (en) * 2013-07-16 2015-11-10 Oracle International Corporation Systems and methods for adaptive integration of hardware and software lock elision techniques
US10061583B2 (en) 2014-12-24 2018-08-28 Intel Corporation Systems, apparatuses, and methods for data speculation execution
US10061589B2 (en) 2014-12-24 2018-08-28 Intel Corporation Systems, apparatuses, and methods for data speculation execution
TWI620122B (en) * 2014-12-24 2018-04-01 英特爾股份有限公司 Apparatuses and methods for data speculation execution
US20160188342A1 (en) * 2014-12-24 2016-06-30 Elmoustapha Ould-Ahmed-Vall Systems, apparatuses, and methods for data speculation execution
US10303525B2 (en) 2014-12-24 2019-05-28 Intel Corporation Systems, apparatuses, and methods for data speculation execution
US10387158B2 (en) * 2014-12-24 2019-08-20 Intel Corporation Systems, apparatuses, and methods for data speculation execution
US10387156B2 (en) 2014-12-24 2019-08-20 Intel Corporation Systems, apparatuses, and methods for data speculation execution
US10942744B2 (en) 2014-12-24 2021-03-09 Intel Corporation Systems, apparatuses, and methods for data speculation execution

Also Published As

Publication number Publication date
CN101807169A (en) 2010-08-18
US8661206B2 (en) 2014-02-25
DE112005002402B4 (en) 2020-11-05
US20140136783A1 (en) 2014-05-15
WO2006039174A1 (en) 2006-04-13
US20110055837A1 (en) 2011-03-03
US20170206159A1 (en) 2017-07-20
JP2008515055A (en) 2008-05-08
US20170206160A1 (en) 2017-07-20
US20170039068A1 (en) 2017-02-09
US10102123B2 (en) 2018-10-16
US9529715B2 (en) 2016-12-27
US10268579B2 (en) 2019-04-23
CN1755635A (en) 2006-04-05
US20060085591A1 (en) 2006-04-20
US10180903B2 (en) 2019-01-15
JP4774056B2 (en) 2011-09-14
CN101807169B (en) 2014-06-25
CN1755635B (en) 2010-05-12
DE112005002402T5 (en) 2007-08-16

Similar Documents

Publication Publication Date Title
US10268579B2 (en) Hybrid hardware and software implementation of transactional memory access
EP2150900B1 (en) Transactional memory using buffered writes and enforced serialization order
US9195600B2 (en) Mechanisms to accelerate transactions using buffered stores
US8365016B2 (en) Performing mode switching in an unbounded transactional memory (UTM) system
US9569254B2 (en) Automatic checkpointing and partial rollback in software transaction memory
US20140156953A1 (en) Unified Optimistic and Pessimistic Concurrency Control for a Software Transactional Memory (STM) System
US20100122073A1 (en) Handling exceptions in software transactional memory systems
WO2014100698A1 (en) Methods and systems for enhancing hardware transactions using hardware transactions in software slow-path
Marathe et al. Scalable techniques for transparent privatization in software transactional memory
Grahn Transactional memory
Lumetta Detection of Synchronization Errors through Speculative Lock Elision
Tabassum et al. Transactional Memory: A Review
WO2024217677A1 (en) Crash-consistent persistent memory devices and methods
Wang et al. Software transactional memory in multicore processors
Harris et al. Hardware-Supported Transactional Memory
CMP importance of parallel programming increases Parallel programming is difficult

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTEL CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KUMAR, SANJEEV;HUGHES, CHRISTOPHER J.;KUNDU, PARTHA;AND OTHERS;REEL/FRAME:016043/0759

Effective date: 20041129

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552)

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12