USPatent applicationPatented

Facilitating concurrent non-transactional execution in a transactional memory system

Granted 2 Sep 2008 · 2 office actions

Assignee: Oracle Corporation

Law firm: Law firm · Log in to unlock

Attorney: Attorney · Log in to unlock

Inventors: Gregory M. Wright, Michael H. Paleczny · Examiner: Donald Sparks · AU 2187 · TC 2100

Application· this page
11/098,134
filed 4 Apr 2005
Publication
Not published
not published
Patent
US 7,421,544
granted 2 Sep 2008

Life of the application

12 dated events
⤢ drag to zoom20062008201020122014201620182020202220242026ProsecutionOwnershipTerm & fees
ProsecutionOwnershipTerm & feeshover for detail · click to open

Abstract

One embodiment of the present invention provides a system that facilitates concurrent non-transactional operations in a transactional memory system. During operation, the system receives a load instruction related to a local transaction. Next, the system determines if an entry for the memory location requested by the load instruction already exists in the transaction buffer. If not, the system allocates an entry for the memory location in the transaction buffer, reads data for the load instruction from the cache, and stores the data in the transaction buffer. Finally, the system returns the data to the processor to complete the load instruction. In this way, if a remote non-transactional store instruction is received during the transaction, the remote non-transactional store proceeds and does not cause the local transaction to abort.

Description

5 parts
›BACKGROUND

1. Field of the Invention

The present invention relates to computer memory systems. More specifically, the present invention relates to a method and an apparatus for facilitating concurrent non-transactional execution in a transactional memory system.

2. Related Art

Computer system designers are presently developing mechanisms to support multi-threading within the latest generation of Chip-Multiprocessors (CMPs) as well as more traditional Shared Memory Multiprocessors (SMPs). With proper hardware support, multi-threading can dramatically increase the performance of numerous applications. However, as microprocessor performance continues to increase, the time spent synchronizing between threads (processes) is becoming a large fraction of overall execution time. In fact, as multi-threaded applications begin to use even more threads, this synchronization overhead becomes the dominant factor in limiting application performance.

From a programmer's perspective, synchronization is generally accomplished through the use of locks. A lock is typically acquired before a thread enters a critical section of code, and is released after the thread exits the critical section. If another thread wants to enter a critical section protected by the same lock, it must acquire the same lock. If it is unable to acquire the lock because a preceding thread has grabbed the lock, the thread must wait until the preceding thread releases the lock. (Note that a lock can be implemented in a number of ways, such as through atomic operations or semaphores.)

Unfortunately, the process of acquiring a lock and the process of releasing a lock are very time-consuming in modern microprocessors. They involve atomic operations, which typically flush the load buffer and store buffer, and can consequently require hundreds, if not thousands, of processor cycles to complete.

One technique to reduce the overhead involved in manipulating locks is to “transactionally” execute a critical section, wherein changes made during the transactional execution are not committed to the architectural state of the processor until the transactional execution completes without encountering an interfering data access from another thread. This technique is described in U.S. Pat. No. 6,862,664, entitled, “Method and Apparatus for Avoiding Locks by Speculatively Executing Critical Sections,” by inventors Shailender Chaudhry, Marc Tremblay and Quinn A. Jacobson, issued on 1 Mar. 2005.

Proposed transactional memory systems typically hold in-progress transactional state in a “transaction buffer” alongside a normal level-one (L1) cache. During transactional execution, memory operations which are directed to the L1 cache are intercepted by the transaction buffer. The transaction buffer holds this information until the transaction is committed.

When the transaction is committed, values in the transaction buffer are committed as a group to the cache. This means that if the transaction commits, all involved memory locations are updated. However, if the transaction aborts, all involved memory locations are not updated and hence retain their original value.

Unfortunately, performance problems can arise when a remote process attempts to access one of the memory locations related to the transaction, particularly when the remote process attempts to store new information in one of the memory locations. In response to the attempted access, the transaction is aborted and must be restarted from the beginning. Alternatively, the remote store may be rejected or stalled until the completion of the transaction. Either response can cause performance problems because the work that was accomplished between the start of the transaction and the abort is lost and must be repeated, or else progress of the remote thread is impeded.

Hence, what is needed is a method and an apparatus to facilitate concurrent non-transactional execution in a transactional memory system without the problems described above.

›SUMMARY

One embodiment of the present invention provides a system that facilitates concurrent non-transactional operations in a transactional memory system. During operation, the system receives a load instruction related to a local transaction. Next, the system determines if an entry for the memory location requested by the load instruction already exists in the transaction buffer. If not, the system allocates an entry for the memory location in the transaction buffer, reads data for the load instruction from the cache, and stores the data in the transaction buffer. Finally, the system returns the data to the processor to complete the load instruction. In this way, if a remote non-transactional store instruction is received during the transaction, the remote non-transactional store proceeds and does not cause the local transaction to abort. Remote non-transactional operations are described in more detail below.

In a variation of this embodiment, the system receives a store instruction related to the local transaction. In response, the system determines if an entry for the memory location addressed by the store instruction is already located in the transaction buffer. If not, the system allocates an entry in the transaction buffer for the memory location, stores the data from the store instruction in the entry, and sets a local stored flag associated with the entry to indicate that the data was stored into the entry.

In a further variation, the system receives a commit instruction for the local transaction. In response, the system determines if the local stored flag is set and the remote stored flag is clear for each entry in the transaction buffer. If so, the system commits the value in the transaction buffer entry to the cache for each entry where the local stored flag is set and the remote stored flag is clear.

In a further variation, upon receiving a remote load instruction related to a remote operation, the system returns data for the remote load instruction from the cache.

In a further variation, upon receiving a remote store instruction related to a remote operation, the system stores data for the remote store instruction into the cache, and, if an entry exists in the transaction buffer for the memory location addressed by the remote store instruction, sets the remote stored flag on that entry.

In a further variation, the local value in the transaction buffer is always a valid value as seen by the local transaction.

In a further variation, a concurrent remote load instruction is serialized before the local transaction, if no concurrent remote store to the same memory location has been serialized after the local transaction; a concurrent remote store instruction is serialized after the local transaction; and a concurrent remote load instruction is serialized after a remote store instruction to the same memory location, if such a remote store instruction has been serialized after the local transaction.

›BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a processor system in accordance with an embodiment of the present invention.

FIG. 2 illustrates a transaction buffer in accordance with an embodiment of the present invention.

FIG. 3 presents a flowchart illustrating the process of responding to a local transactional load instruction in accordance with an embodiment of the present invention.

FIG. 4 presents a flowchart illustrating the process of responding to a local transactional store instruction in accordance with an embodiment of the present invention.

FIG. 5 presents a flowchart illustrating the process of responding to a remote non-transactional load instruction in accordance with an embodiment of the present invention.

FIG. 6 presents a flowchart illustrating the process of responding to a remote non-transactional store instruction in accordance with an embodiment of the present invention.

FIG. 7 presents a flowchart illustrating the process of responding to a commit instruction in accordance with an embodiment of the present invention.

›DETAILED DESCRIPTION · 1 of 2

The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs or digital video discs).

Processor System

FIG. 1 illustrates a processor system 100 in accordance with an embodiment of the present invention. Processor system 100 includes processors 102 and 104 and memory controller 118 . Processor 102 includes cache 106 which, in turn, includes cache line 108 . Cache line 108 may be involved in a transaction as described further in conjunction with FIG. 2 . Similarly, processor 104 includes cache 105 .

During operation, processor 104 may generate a load 110 to retrieve data from a memory location that is currently stored in cache line 108 in cache 106 . Upon receiving load 110 , memory controller 118 recognizes that the current value for the associated memory location is stored in cache line 108 and sends a remote load request 112 to processor 102 . In response, processor 102 provides data 114 to memory controller 118 . Memory controller 118 , in turn, returns data 114 to processor 104 .

Transaction Buffer

FIG. 2 illustrates a transaction buffer 202 in accordance with an embodiment of the present invention. Transaction buffer 202 is initialized at the start of a transaction and maintains the current value for each accessed memory location until the transaction is committed.

During the transaction, each cache location that is referenced is allocated an entry 212 in transaction buffer 202 . For example, if cache line 108 is referenced by a load associated with the transaction, an entry is allocated for the addressed location in transaction buffer 202 . The address for the location is stored in address field 206 of the allocated entry and the associated data is stored in value field 208 of the allocated entry. Stored bits 210 and 211 are cleared to indicate that neither the local transaction nor a remote store has changed the value in the location.

When the transaction is committed, each entry that has been updated by the transaction is committed 214 to cache 106 . This commit process is described in detail below in conjunction with FIG. 7

Local Transactional Load Instruction

FIG. 3 presents a flowchart illustrating the process of responding to a local transactional load instruction in accordance with an embodiment of the present invention. The system starts when a local transactional load instruction is received (step 302 ). Next, the system determines if there is an entry in the transaction buffer for the addressed location (step 304 ).

If not, the system allocates an entry for the load in the transaction buffer (step 306 ). Next, the system reads the data for the load from the cache (step 308 ) and stores the data in the local value field of the allocated entry in the transaction buffer (step 310 ). If there was already an entry in the transaction buffer at step 304 or after storing data in a new entry at step 310 , the system returns to the processor the local value from the entry in the transaction buffer to complete the load instruction (step 312 ).

Local Transactional Store Instruction

FIG. 4 presents a flowchart illustrating the process of responding to a local transactional store instruction in accordance with an embodiment of the present invention. The system starts when a local transactional store instruction is received (step 402 ). Next, the system determines if there is already an entry in the transaction buffer for the memory location addressed by the store instruction (step 404 ).

If not, the system allocates an entry in the transaction buffer (step 406 ). After an entry is allocated in the transaction buffer for the store, the system stores the data in the local value field of the entry (step 408 ). Finally, the system sets the local stored flag associated with the entry in the transaction buffer (step 410 ).

Remote Non-Transactional Load Instruction

FIG. 5 presents a flowchart illustrating the process of responding to a remote non-transactional load instruction in accordance with an embodiment of the present invention. The system starts when a remote non-transactional load instruction is received (step 502 ). In response, the system returns the cached value for the requested data (step 504 ). Note that this remote non-transactional load instruction does not interfere with the transaction.

Remote Non-Transactional Store Instruction

FIG. 6 presents a flowchart illustrating the process of responding to a remote non-transactional store instruction in accordance with an embodiment of the present invention. The system starts when a remote non-transactional store instruction is received (step 602 ). In response, the system modifies the cache entry associated with the destination memory location of the store instruction (step 604 ). Note that unlike in a conventional transactional memory system, this remote non-transactional store instruction does not interfere with the transaction. In addition, the system determines if there is an entry in the transaction buffer for the destination memory location of the store instruction (step 606 ). If so, the system sets the remote stored flag of the entry (step 608 ).

›DETAILED DESCRIPTION · 2 of 2

Commit Instruction

FIG. 7 presents a flowchart illustrating the process of processing a commit instruction in accordance with an embodiment of the present invention. The system starts when a commit instruction is received for the transaction (step 702 ). In response, the system inspects the transaction buffer to determine if the local stored flag is set and the remote stored flag is not set for an entry in the transaction buffer (step 704 ). If so, the system commits the value in the entry to the cache (step 706 ).

After committing the value at step 706 , or if the local stored flag is not set or the remote stored flag is set at step 704 , the system determines if all transaction buffer entries have been examined (step 708 ). If not, the system returns to step 704 to inspect another entry in the transaction buffer. Otherwise, the process is complete.

The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.

Claims as granted

21 claims

Log in to read the claims of this application.

Log in to unlock

Classifications

7 codes
IPC · International Patent Classification
Section G — Physics
  • G06F12/16
USPC · US Patent Classification
711/150711/152718/100711/170711/151718/101

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this application are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoomJul 2005Jan 2006Jul 2006Jan 2007Jul 2007Jan 2008Jul 2008USPTOApplicantNon-final rejectionResponse after non-finalResponse after finalNotice of allowance
USPTOApplicanthover for detail · click to open
Pendency
3.4 y
1,247 days filing → grant
Office actions
2
non-final + final
Responses
2
1 RCE
Examiner
Donald Sparks
art unit 2187 · TC 2100
Citations: 4 back · 80 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Documents

Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.

Log in to unlock

Chain of title

⤢ drag to zoom20062008201020122014201620182020202220242026Owner 1Owner 2
Titlehover for detail · click to open

See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.

Log in to unlock