US20140013055A1 - Ensuring causality of transactional storage accesses interacting with non-transactional storage accesses - Google Patents
Ensuring causality of transactional storage accesses interacting with non-transactional storage accesses Download PDFInfo
- Publication number
- US20140013055A1 US20140013055A1 US13/777,161 US201313777161A US2014013055A1 US 20140013055 A1 US20140013055 A1 US 20140013055A1 US 201313777161 A US201313777161 A US 201313777161A US 2014013055 A1 US2014013055 A1 US 2014013055A1
- Authority
- US
- United States
- Prior art keywords
- memory
- transaction
- transactional
- store
- instruction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
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/0842—Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
-
- 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/0813—Multiuser, multiprocessor or multiprocessing cache systems with a network or matrix configuration
-
- 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
- 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
Definitions
- the present invention relates generally to data processing and, in particular, to storage accesses to the shared distributed memory system of a data processing system. Still more particularly, the present invention relates to ensuring causality of transactional storage accesses interacting with non-transactional storage accesses.
- a conventional multiprocessor (MP) computer system such as a server computer system, includes multiple processing units all coupled to a system interconnect, which typically comprises one or more address, data and control buses. Coupled to the system interconnect is a system memory, which represents the lowest level of volatile memory in the multiprocessor computer system and which generally is accessible for read and write access by all processing units.
- system memory which represents the lowest level of volatile memory in the multiprocessor computer system and which generally is accessible for read and write access by all processing units.
- each processing unit is typically further supported by a respective multi-level cache hierarchy, the lower level(s) of which may be shared by one or more processor cores.
- Cache memories are commonly utilized to temporarily buffer memory blocks that might be accessed by a processor in order to speed up processing by reducing access latency introduced by having to load needed data and instructions from system memory.
- the cache hierarchy includes at least two levels.
- the level one (L1) or upper-level cache is usually a private cache associated with a particular processor core and cannot be accessed by other cores in an MP system.
- the processor core in response to a memory access instruction such as a load or store instruction, the processor core first accesses the directory of the upper-level cache. If the requested memory block is not found in the upper-level cache, the processor core then accesses lower-level caches (e.g., level two (L2) or level three (L3) caches) or system memory for the requested memory block.
- the lowest level cache e.g., L3 cache
- L3 cache is often shared among several processor cores.
- multiprocessor software concurrently accesses shared data structures from multiple software threads.
- shared data it is typically necessary to prevent so-called “unconstrained races” or “conflicts”.
- a conflict occurs between two memory accesses when they are to the same memory location and at least one of them is a write and there is no means to ensure the ordering in which those accesses occur.
- Multiprocessor software typically utilizes lock variables to coordinate the concurrent reading and modifying of locations in memory in an orderly conflict-free fashion.
- a lock variable is a location in memory that is read and then set to a certain value, possibly based on the value read, in an atomic fashion.
- the read-modify-write operation on a lock variable is often accomplished utilizing an atomic-read-modify-write (ARMW) instruction or by a sequence of instructions that provide the same effect as a single instruction that atomically reads and modifies the lock variable.
- ARMW atomic-read-modify-write
- a software thread reading an initial “unlocked” value via an ARMW instruction is said to have “acquired” the lock and will, until it releases the lock, be the only software thread that holds the lock.
- the thread holding the lock may safely update the shared memory locations protected by the lock without conflict with other threads because the other threads cannot obtain the lock until the current thread releases the lock.
- the thread holding the lock releases the lock (e.g., by writing the lock variable to the “unlocked” value) to allow other threads to access the shared locations in storage.
- transactional memory a set of load and/or store instructions are treated as a “transaction.”
- a transaction succeeds when the constituent load and store operations can occur atomically without a conflict with another thread.
- the transaction fails in the presence of a conflict with another thread and can then be re-attempted. If a transaction continues to fail, software may fall back to using locking to ensure the orderly access of shared data.
- the underlying hardware tracks the storage locations involved in the transaction—the transaction footprint—as the transaction executes for conflicts. If a conflict occurs in the transaction footprint, the transaction is aborted and possibly restarted.
- Use of transactional memory reduces the possibility of deadlock due to a thread holding multiple locks because, in the typical case, no locks are held (the transaction simply attempts to make one or more storage accesses and restarts if a conflict occurs). Further, the processing overhead of acquiring a lock is generally avoided.
- a data processing system implements a weak consistency memory model for a distributed shared memory system.
- the data processing system concurrently executes, on a plurality of processor cores, one or more transactional memory instructions within a memory transaction and one or more non-transactional memory instructions.
- the one or more non-transactional memory instructions include a non-transactional store instruction.
- the data processing system commits the memory transaction to the distributed shared memory system only in response to enforcement of causality of the non-transactional store instruction with respect to the memory transaction.
- FIG. 1 is a high-level block diagram of an exemplary data processing system in accordance with one embodiment
- FIG. 2 is a more detailed block diagram of an exemplary processing unit in accordance with one embodiment
- FIG. 3 is a detailed block diagram of lower level cache supporting memory transactions in accordance with one embodiment
- FIG. 4 is an illustrative example of a memory transaction in accordance with one embodiment
- FIG. 5 is an illustrative example of a memory transaction including a suspend region in accordance with one embodiment
- FIG. 6A depicts execution of an exemplary program illustrating causality in a multiprocessor data processing system
- FIG. 6B illustrates execution of an exemplary program including memory transactions to ensure causality
- FIG. 6C depicts execution of an exemplary program including both transactional and non-transactional memory accesses
- FIG. 7 illustrates a multiprocessor data processing system including at least three processor cores that execute the exemplary program of FIG. 6C ;
- FIG. 8 is a high level logical flowchart of an exemplary method by which a multiprocessor data processing system ensures causality in execution of a program including both transactional and non-transactional memory accesses;
- FIG. 9 is a data flow diagram illustrating a design process.
- data processing system 100 is a cache coherent symmetric multiprocessor (SMP) data processing system including multiple processing nodes 102 a , 102 b for processing data and instructions.
- SMP cache coherent symmetric multiprocessor
- Processing nodes 102 are coupled to a system interconnect 110 for conveying address, data and control information.
- System interconnect 110 may be implemented, for example, as a bused interconnect, a switched interconnect or a hybrid interconnect.
- each processing node 102 is realized as a multi-chip module (MCM) containing four processing units 104 a - 104 d , each preferably realized as a respective integrated circuit.
- MCM multi-chip module
- the processing units 104 within each processing node 102 are coupled for communication to each other and system interconnect 110 by a local interconnect 114 , which, like system interconnect 110 , may be implemented, for example, with one or more buses and/or switches.
- System interconnect 110 and local interconnects 114 together form a system fabric.
- processing units 104 each include a memory controller 106 coupled to local interconnect 114 to provide an interface to a respective system memory 108 .
- Data and instructions residing in system memories 108 can generally be accessed, cached and modified by a processor core in any processing unit 104 of any processing node 102 within data processing system 100 .
- System memories 108 thus form the lowest level of volatile storage in the distributed shared memory system of data processing system 100 .
- one or more memory controllers 106 can be coupled to system interconnect 110 rather than a local interconnect 114 .
- SMP data processing system 100 of FIG. 1 can include many additional non-illustrated components, such as interconnect bridges, non-volatile storage, ports for connection to networks or attached devices, etc. Because such additional components are not necessary for an understanding of the described embodiments, they are not illustrated in FIG. 1 or discussed further herein. It should also be understood, however, that the enhancements described herein are applicable to cache coherent data processing systems of diverse architectures and are in no way limited to the generalized data processing system architecture illustrated in FIG. 1 .
- Multiprocessor data processing system such as data processing system 100 of FIG. 1 implement a memory consistency model that specifies the legal possible executions of a given multiprocessor program with respect to memory accesses (e.g., among other things, the values that may be returned by load instructions, the order of writes to memory, those instruction execution dependencies that affect the ordering of memory accesses, and the final values for memory locations at the conclusion of a multiprocessor program).
- a memory consistency model is specified by two major characteristics: ordering of memory access operations and atomicity of store operations.
- the ordering of memory operations specifies how memory operations may, if at all, be re-ordered relative to the order of their respective load and store instructions in the individual threads of execution in the multiprocessor program.
- Strong consistency memory models will, in general, preserve all or at least most of these orderings. In particular, many strong consistency memory models enforce the first three orderings, but do not enforce store-to-load ordering. Weak consistency memory models will generally not enforce most or all of these orderings.
- Atomicity of store operations refers to whether or not a given thread of execution can read the value of its own store operation before other threads, and furthermore, whether the value written to the distributed shared memory system by the store operation becomes visible to other threads in a logically instantaneous fashion or whether the value can become visible to other threads at different points in time.
- a memory consistency model is called “multi-copy atomic” if the value written by a store operation of one thread becomes visible to all other threads in a logically instantaneous fashion.
- strong consistency memory models are multi-copy atomic, and weak consistency memory models do not enforce multi-copy atomicity.
- barrier e.g., SYNC
- each processing unit 104 is an integrated circuit including two or more processor cores 200 a , 200 b for processing instructions and data.
- each processor core 200 is capable of independently executing multiple hardware threads of execution simultaneously.
- each processor core 200 includes one or more execution units, such as load-store unit (LSU) 202 , for executing instructions.
- the instructions executed by LSU 202 include memory access instructions that request load or store access to a memory block in the distributed shared memory system or cause the generation of a request for load or store access to a memory block in the distributed shared memory system.
- Memory blocks obtained from the distributed shared memory system by load accesses are buffered in one or more register files (RFs) 208 , and memory blocks are written to the distributed shared memory system from the one or more register files 208 .
- RFs register files
- each processor core 200 is supported by a multi-level volatile memory hierarchy having at its lowest level a shared system memory 108 accessed via an integrated memory controller 106 , and at its upper levels, one or more levels of cache memory, which in the illustrative embodiment include a store-through level one (L1) cache 226 within and private to each processor core 200 , and a respective store-in level two (L2) cache 230 for each processor core 200 a , 200 b .
- L1 cache 226 within and private to each processor core 200
- L2 cache 230 for each processor core 200 a , 200 b .
- each L2 cache 230 can be implemented with multiple L2 cache slices, each of which handles memory access requests for a respective set of real memory addresses.
- cache hierarchies includes only two levels of cache, those skilled in the art will appreciate that alternative embodiments may include additional levels (L3, L4, etc.) of on-chip or off-chip, private or shared, in-line or lookaside cache, which may be fully inclusive, partially inclusive, or non-inclusive of the contents the upper levels of cache.
- L3, L4, etc. additional levels of on-chip or off-chip, private or shared, in-line or lookaside cache, which may be fully inclusive, partially inclusive, or non-inclusive of the contents the upper levels of cache.
- Each processing unit 104 further includes an integrated and distributed fabric controller 216 responsible for controlling the flow of operations on the system fabric comprising local interconnect 114 and system interconnect 110 and for implementing the coherency communication required to implement the selected cache coherency protocol.
- Processing unit 104 further includes an integrated I/O (input/output) controller 214 supporting the attachment of one or more I/O devices (not depicted).
- LSU 202 executes the memory access instruction to determine the target address of the memory access request. After translation of the target address to a real address, L1 cache 226 is accessed utilizing the target address. Assuming the indicated memory access cannot be satisfied solely by reference to L1 cache 226 , LSU 202 then transmits the memory access request, which includes at least a transaction type (ttype) (e.g., load or store) and the target real address, to its affiliated L2 cache 230 for servicing.
- ttype transaction type
- L2 cache 230 includes a cache array 302 and a directory 308 of the contents of cache array 302 .
- cache array 302 preferably is implemented with a single read port and single write port to reduce the die area required to implement cache array 302 .
- cache array 302 and directory 308 are set associative as is conventional, memory locations in system memories 108 are mapped to particular congruence classes within cache array 302 utilizing predetermined index bits within the system memory (real) addresses.
- the particular memory blocks stored within the cache lines of cache array 302 are recorded in cache directory 308 , which contains one directory entry for each cache line. While not expressly depicted in FIG.
- each directory entry in cache directory 308 includes various fields, for example, a tag field that identifies the real address of the memory block held in the corresponding cache line of cache array 302 , a state field that indicate the coherency state of the cache line, an LRU (Least Recently Used) field indicating a replacement order for the cache line with respect to other cache lines in the same congruence class, and inclusivity bits indicating whether the memory block is held in the associated L1 cache 226 .
- a tag field that identifies the real address of the memory block held in the corresponding cache line of cache array 302
- a state field that indicate the coherency state of the cache line
- an LRU (Least Recently Used) field indicating a replacement order for the cache line with respect to other cache lines in the same congruence class
- inclusivity bits indicating whether the memory block is held in the associated L1 cache 226 .
- L2 cache 230 includes multiple (e.g., 16) Read-Claim (RC) machines 312 for independently and concurrently servicing load (LD) and store (ST) requests received from the affiliated processor core 200 .
- L2 cache 230 also includes multiple snoop machines 311 .
- Each snoop machine 311 can independently and concurrently handle a remote memory access request “snooped” from local interconnect 114 .
- the servicing of memory access requests by RC machines 312 may require the replacement or invalidation of memory blocks within cache array 302 .
- L2 cache 230 includes CO (castout) machines 310 that manage the removal and writeback of memory blocks from cache array 302 .
- L2 cache 230 further includes an arbiter 305 that controls multiplexers M 1 -M 2 to order the processing of local memory access requests received from affiliated processor core 200 and remote requests snooped on local interconnect 114 .
- Memory access requests including local and remote load and store operations, are forwarded in accordance with the arbitration policy implemented by arbiter 305 to dispatch logic, such as a dispatch pipeline 306 , which processes each read/load and store request with respect to directory 308 and cache array 302 .
- transactional memory (TM) logic 380 tracks memory access operations within memory transactions to ensure completion of the memory access operations in an atomic manner or to abort the memory transactions in the presence of conflicts.
- L2 cache 230 also includes an RC queue 320 and a CPI (castout push intervention) queue 318 that respectively buffer data being inserted into and removed from the cache array 302 .
- RC queue 320 includes a number of buffer entries that each individually correspond to a particular one of RC machines 312 such that each RC machine 312 that is dispatched retrieves data from only the designated buffer entry.
- CPI queue 318 includes a number of buffer entries that each individually correspond to a particular one of the castout machines 310 and snoop machines 311 , such that each CO machine 310 and each snooper 311 that is dispatched retrieves data from only the respective designated CPI buffer entry.
- Each RC machine 312 also has assigned to it a respective one of multiple RC data (RCDAT) buffers 322 for buffering a memory block read from cache array 302 and/or received from local interconnect 114 via reload bus 323 .
- the RCDAT buffer 322 assigned to each RC machine 312 is preferably constructed with connections and functionality corresponding to the memory access requests that may be serviced by the associated RC machine 312 .
- RCDAT buffers 322 have an associated store data multiplexer M 4 that selects data bytes from among its inputs for buffering in the RCDAT buffer 322 in response unillustrated select signals generated by arbiter 305 .
- a processor core 200 transmits store requests comprising a transaction type (ttype), target real address and store data to a store queue (STQ) 304 .
- STQ 304 the store data are transmitted to store data multiplexer M 4 via data path 324 , and the transaction type and target address are passed to multiplexer M 1 .
- Multiplexer M 1 also receives as inputs processor load requests from processor core 200 and directory write requests from RC machines 312 .
- multiplexer M 1 selects one of its input requests to forward to multiplexer M 2 , which additionally receives as an input a remote request received from local interconnect 114 via remote request path 326 .
- Arbiter 305 schedules local and remote memory access requests for processing and, based upon the scheduling, generates a sequence of select signals 328 .
- select signals 328 generated by arbiter 305 multiplexer M 2 selects either the local request received from multiplexer M 1 or the remote request snooped from local interconnect 114 as the next memory access request to be processed.
- the request selected for processing by arbiter 305 is placed by multiplexer M 2 into dispatch pipeline 306 .
- Dispatch pipeline 306 preferably is implemented as a fixed duration pipeline in which each of multiple possible overlapping requests is processed for a predetermined number of clock cycles (e.g., 4 cycles).
- a directory read is performed utilizing the request address to determine if the request address hits or misses in directory 308 , and if the memory address hits, the coherency state of the target memory block.
- the directory information which includes a hit/miss indication and the coherency state of the memory block, is returned by directory 308 to dispatch pipeline 306 in a subsequent cycle.
- L2 cache 230 will service the memory access request, which for requests that cannot be serviced entirely within processing unit 104 , may entail communication on local interconnect 114 via fabric controller 216 .
- arbiter 305 transmits the request address to cache array 302 via address and control path 330 to initiate a cache read 402 of the memory block specified by the request address.
- the memory block read from cache array 302 is transmitted via data path 342 to Error Correcting Code (ECC) logic 344 , which checks the memory block for errors and, if possible, corrects any detected errors.
- ECC Error Correcting Code
- the memory block is also transmitted to load data multiplexer M 3 via data path 340 for forwarding to the affiliated processor core 200 .
- dispatch pipeline 306 makes a dispatch determination based upon a number of criteria, including (1) the presence of an address collision between the request address and a previous request address currently being processed by a castout machine 310 , snoop machine 311 or RC machine 312 , (2) the directory information, and (3) availability of an RC machine 312 or snoop machine 311 to process the memory access request. If dispatch pipeline 306 makes a dispatch determination that the memory access request is to be dispatched, the memory access request is dispatched from dispatch pipeline 306 to an RC machine 312 or a snoop machine 311 . If the memory access request fails dispatch, the failure is signaled to the requestor (e.g., local or remote processor core 200 ) by a retry response. The requestor may subsequently retry the failed memory access request, if necessary.
- the requestor e.g., local or remote processor core 200
- RC machines 312 Associated with RC machines 312 is data handling circuitry, different portions of which are employed during the servicing of various types of local memory access requests. For example, for a local load request that hits in directory 308 , an uncorrected copy of the target memory block is forwarded from cache array 302 to the affiliated processor core 200 via data path 340 and load data multiplexer M 3 and additionally forwarded to ECC logic 344 via data path 342 . In the case of an ECC error in the target memory block obtained by the local load request, corrected data is forwarded to RCDAT buffer 322 via data path 346 and store data multiplexer M 4 and then from RCDAT 322 to affiliated processor core 200 via data path 360 and load data multiplexer M 3 .
- store data is received within RCDAT buffer 322 from STQ 304 via data path 324 and store data multiplexer M 4 , the store is merged with the memory block read into RCDAT buffer 322 from cache array 302 via ECC logic 344 and store data multiplexer M 4 , and the merged store data is then written from RCDAT buffer 322 into cache array 302 via data path 362 .
- the target memory block acquired through issuing a memory access operation on local interconnect 114 is loaded into cache array 302 via reload bus 323 , store data multiplexer M 4 , RCDAT buffer 322 (with store merge for a store miss) and data path 362 .
- FIG. 4 an illustrative example of a memory transaction is depicted.
- Those skilled in the art will recognize that the particular semantics and instructions utilized to implement a memory transaction are but one possible implementation and that the disclosed techniques of implementing transactional memory are not dependent on the specific instructions and instruction semantics employed.
- Illustrative memory transaction 400 begins at tbegin instruction 402 .
- the tbegin instruction 402 initiates the memory transaction, causes the processor core 200 executing tbegin instruction 402 to take a checkpoint 210 of the architected register state of processor core 200 , and invokes tracking of load and store instructions within the transaction body 406 to ensure they complete in an atomic fashion or that memory transaction 400 fails in the presence of a conflict.
- Memory transaction 400 additionally includes a branch instruction 404 immediately following tbegin instruction 402 .
- the condition code register upon which branch instruction 404 depends is initialized to a value that causes the program branch indicated by branch instruction 404 not to be taken and the flow of execution to continue to transaction body 406 .
- the condition code register is set to a different value, and branch instruction 404 causes execution to branch to a fail handler.
- TM logic 380 tracks memory access (e.g., load and store) instructions within transaction body 406 to ensure that they complete in an atomic fashion or that memory transaction 400 fails in the presence of a conflict.
- TM tracking logic 381 includes a number of entries that indicate which cache lines in cache array 302 are included in the transaction footprint.
- the transaction footprint includes two portions: the load footprint corresponding to cache lines touched solely by loads within transaction body 406 (e.g., the cache line at address A in exemplary memory transaction 400 ) and the store footprint corresponding to cache lines touched solely by store instructions or by both load and store instructions in transaction body 406 (e.g., the cache line at address B in exemplary memory transaction 400 ).
- TM logic 380 further includes transactional control logic 382 , which controls the sequencing of a memory transaction and provides a pass/fail indication 384 and an optional TM killed indication 385 to the associated processor core 200 .
- Pass/fail indication 384 indicates to processor core 200 whether or not the memory transaction successfully committed at the execution of the tend instruction 408 at the end of memory transaction 400 .
- TM kill indication 385 indicates to processor core 200 whether or not a conflict has occurred during the transaction.
- processor core 200 may, as a performance optimization, optionally abort and restart memory transaction 400 prior to reaching tend instruction 408 .
- processor core 200 In response to pass/fail indication 384 (or optionally TM kill indication 385 ) indicating that a conflict has occurred during execution of memory transaction 400 , processor core 200 re-establishes its architected register state from the checkpoint 210 taken at the execution of tbegin instruction 402 , invalidates the tentatively modified cache lines in the store footprint, releases tracking logic 381 , sets the condition code register such that branch instruction 404 will be taken, and transfers control to branch instruction 404 . In addition, processor core 200 sets a transaction failure cause register (not shown) in processor core 200 to indicate the cause of the transaction's failure. The fail handler routine invoked by branch instruction 404 may choose to re-attempt memory transaction 400 or fall back to more conventional locking mechanisms, optionally based on the content of the transaction failure cause register.
- the values stored to the distributed shared memory system by transaction body 406 are visible only to the thread of the processor core 200 executing the memory transaction. Threads running on the same or other processor cores 200 will not see these values until and only if the memory transaction successfully commits.
- transactional control logic 382 indicates to processor core 200 via pass/fail indication 384 that memory transaction 400 passed and commits all stores performed in transaction body 406 to L2 cache 230 , thus making them visible to all other threads and processor cores 200 in the system simultaneously.
- a load or store will be called “transactional” if that load or store instruction occurs within the transaction body 406 of a memory transaction 400 .
- a load or store will be called “non-transactional” if it occurs outside a transaction body 406 .
- a conflict policy of data processing system 100 defines a conflict with another processor core's memory access to occur for a given memory transaction in any one of several possible cases. In a first case, a conflict occurs if a non-transactional store from another processor core 200 hits a cache line within either the given memory transaction's load or store footprint.
- a conflict occurs if a transactional store from another processor core 200 hits a cache line within the given memory transaction's load footprint.
- a conflict occurs if a non-transactional load hits a cache line within the given memory transaction's store footprint.
- a conflict occurs if a transactional load from another processor core 200 hits a cache line within the given memory transaction's store footprint.
- the given memory transaction has a conflict if one of its transactional stores hits an address already extant in the store footprint of another processor core's memory transaction.
- This exemplary conflict policy is but one of several possible embodiments of transactional memory. The above conflict policy biases in favor of transactional stores over transactional loads, while allowing transactional and non-transactional loads to freely intermingle.
- memory transaction 500 includes a tbegin instruction 502 , branch instruction 504 , transaction body 506 and tend instruction 508 , which correspond to tbegin instruction 402 , branch instruction 404 , transaction body 406 and tend instruction 408 described above.
- memory transaction 500 includes a tsuspend instruction 510 that initiates the start of a suspended region 512 .
- TM tracking logic 381 When a memory transaction is suspended through execution of tsuspend instruction 510 , the load and store footprints currently established for the enclosing memory transaction containing suspended region 512 remain in place and continue to be tracked by TM tracking logic 381 for conflicts. However, any load or store instructions within suspended region 512 are treated as non-transactional loads and stores and follow existing semantics for such loads and stores. In particular, stores within suspended region 512 are non-transactional and will commit and begin propagating to other processors unconditionally. If a store within suspended region 512 hits either the load or the store footprint of the enclosing transaction, a conflict occurs (which also destroys the tentative transactional version of the cache line in the store footprint) and is logged by transactional control logic 382 .
- a suspended region 512 allows the temporary suspension of a memory transaction, which permits store instructions in the suspended region 512 to unconditionally update locations in the shared distributed memory system while also allowing for the resumption of the memory transaction at a later time.
- One possible use for a suspended region 512 is to log debug information into a scratchpad region of the distributed shared memory system and then to resume the enclosing memory transaction. Without a suspended region, the write of the debug information would be rolled back any time the enclosing memory transaction is aborted.
- causality which is desirable property in multiprocessor programs, is defined as being preserved if, during execution of a multiprocessor program, a given thread of execution cannot read the effects of a computation before the writes that caused the computation can be read by the given thread.
- a multiprocessor program is executed by three processor cores 200 of data processing system 100 , labeled for ease of reference as processor core 0 , processor core 1 and processor core 2 .
- processor core 0 executes a store instruction 600 that writes a value of 1 to address A in the shared distributed memory system.
- This update of address A propagates to processor core 1
- load instruction 610 executed by processor core 1 therefore returns a value of 1.
- barrier instruction 612 ensures that store instruction 614 does not take effect or begin propagating its memory update to other processor cores until load instruction 610 has bound to its value.
- barrier instruction 612 also ensures that the memory update associated with store instruction 600 propagates to processor 2 before the memory update associated with store instruction 614 .
- causality is preserved because the cause of the computation (i.e., the memory update of store instruction 600 ) is visible to processor core 2 before the result of the computation (i.e., the memory update of store 614 ).
- a barrier instruction 622 is also executed by processor core 2 to ensure that processor core 2 executes load instructions 620 and 624 and binds their values in order, thus guaranteeing that processor core 2 properly observes the memory updates made by processor core 0 and processor core 1 .
- FIG. 6B an exemplary embodiment of the multiprocessor program of FIG. 6A rendered in terms of memory transactions is illustrated.
- the branch instructions to the memory transaction fail handler are omitted for clarity.
- processor core 0 executes a memory transaction 630 including a tbegin instruction 632 , tend instruction 636 , and a transaction body including a store instruction 634 that stores a value of 1 to address A.
- memory transaction 600 successfully commits and makes the update to address A visible to all the other processor cores simultaneously.
- load instruction 642 of the memory transaction 640 executing on processor core 1 can read the value of 1 from address A
- load instruction 654 of the memory transaction 650 executing on processor core 2 must also be able to read the value of 1 for address A.
- Memory transaction 640 then reads the value of 1 for address A, stores a value of 1 to address B and successfully commits.
- load instruction 652 of memory transaction 650 reads a value of 1 for address B, and given that memory transaction 640 read a value of 1 for A, load instruction 654 must also read a value of 1 for address A.
- causality is trivially preserved when only memory transactions are utilized to access memory locations in a shared distributed memory system.
- causality is not directly preserved by ensuring that the memory updates made by a transaction are visible simultaneously to all other processor cores.
- processor core 0 executes a non-transactional store instruction 660 that unconditionally writes a value of 1 to address A in the shared distributed memory system. This value propagates to processor core 1 and is read by transactional load instruction 672 within the memory transaction 670 executed by processor core 1 .
- Processor core 1 then executes a store instruction 674 within memory transaction 670 that updates the cache line associated with address B and completes invalidating any stale cached copies of the cache line associated with address B (so that no other processor core holds a copy of the now stale cache line) and successfully commits memory transaction 670 upon execution of tend instruction 676 .
- Processor core 2 then executes load instructions 680 and 684 to read, in order, the cache lines associated with addresses B and A, respectively, based on the ordering enforced by barrier instruction 682 . If transaction 670 only ensures that its own memory updates are fully propagated through the distributed shared memory system before committing, the memory update of store instruction 660 may or may not have propagated to processor core 2 .
- processor core 2 could read a value of 1 for the cache line associated with address B and the, now stale, initial value of 0 for the cache line associated with address A, thus violating causality. The same result would be obtained if processor core 2 utilized transactional loads to read from addresses A and B, as depicted for processor 2 in FIG. 6B .
- memory transaction 670 must ensure not only that its own transactional stores are propagated throughout the entire distributed shared memory system, but also that any non-transactional store that is read by a transactional load within the transaction has also propagated throughout the distributed shared memory system. (Memory updates of transactional writes that are read by the memory transaction are guaranteed to have propagated throughout the distributed shared memory system because those memory updates could not be read by transaction 670 before they were visible to the entire distributed shared memory system).
- the processing of the tend instruction 676 of memory transaction 670 must not allow commitment of memory transaction 670 until the memory update of any non-transactional store read by memory transaction 670 is propagated throughout the distributed shared memory system.
- processor cores 200 a , 200 b and 200 c respectively correspond to processor cores 0 , 1 and 2 of FIG. 6C .
- an instance of causality resolution logic 379 is instantiated for and coupled to each instance of snooper 311 , for example, as a component of the L2 cache 230 affiliated with each processor core 200 .
- processor core 200 c holds a cached copy of the initial value (e.g., 0) of memory location A in its L1 cache 226 c .
- Processor 200 a begins execution of the multiprocessor program of FIG. 6C by executing store instruction 660 .
- processor core 200 a transmits a store request to its L2 cache 230 a , which allocates an RC machine 312 to service the store request.
- RC machine 312 broadcasts the store request onto local interconnect 114 , and snoop machine 311 c of the L2 cache 230 c affiliated with processor core 200 c registers the store request, including the processing unit that sourced the store request (i.e., the processing unit including processor core 200 a ).
- the memory update of store instruction 660 has not propagated to processor core 200 c , but is instead queued for later processing, advantageously allowing processor core 200 a to continue executing further instructions before the memory update of store instruction 660 is fully propagated.
- Processor core 200 b then executes load instruction 672 and, finding no copy of the target cache line associated with address A in its L1 cache 226 b , transmits a read request to its L2 cache 230 b .
- L2 cache 230 b allocates RC machine 312 b to service the read request.
- RC machine 312 b issues a read request onto local interconnect 114 to obtain the current value for address A.
- L2 cache 230 a responds to the read request and provides the current value of address A to processor core 200 b by cache-to-cache intervention.
- causality resolution logic 379 c in L2 cache 230 c notes the successful read intervention between the vertical cache hierarchies of processor cores 200 a and 200 b for an address that is currently being invalidated by snoop machine 311 c . In this manner causality resolution logic 379 c directly tracks the causal dependency processor 200 b and its vertical cache hierarchy has on the memory update of store instruction 660 completing its propagation.
- Processor 200 b executes store instruction 674 , which specifies an update of the value of address B to 1.
- RC machine 312 b issues a store request corresponding to store instruction 674 on local interconnect 114 .
- memory controller 106 supplies the current value of address B from system memory 108 in response to the store request, and RC machine 312 b updates L2 cache 230 b accordingly.
- processor core 1 executes tend instruction 676 to attempt to successfully commit transaction 670 and places a corresponding TEND request on local interconnect 114 to ensure that all prior memory updates by transactional stores in memory transaction 670 have been propagated throughout the distributed shared memory system and that any memory updates by non-transactional stores read by memory transaction 670 have similarly propagated throughout the distributed shared memory system.
- the memory update of store instruction 674 has fully propagated throughout the distributed shared memory system because no other caches held a copy of the cache line associated with address B.
- a snoop machine 311 in those caches which noted the initial processor core 200 issuing the store, would be active and would retry the snooped TEND request from that processor core 200 until the invalidation of the cached copy of the cache line completes.
- causality resolution logic 379 c has a causal dependency for processor 200 b and its vertical cache hierarchy and issues on local interconnect 114 a retry response to the TEND request because the TEND request was issued from a processor core 200 that was the recipient of a causality passing read of the same address that snoop machine 311 c is processing. In this manner, causality resolution logic 379 directly tracks which processor cores 200 have a causality dependency due to reading a memory update of a non-transactional store that was not fully completed for the processor core with which causality resolution logic 379 is associated.
- causality resolution logic 379 must maintain a list capable of representing all the processors core 200 in the data processing system to provide causality in cases in which the causality dependency chain passes through more than one processor core (e.g., a test where a first processor stores a location, a second processor reads that location and then stores a first flag variable, a third processor loads the first flag variable and writes a second flag in a transaction, and then a final thread reads the second flag and then the initial location).
- a TEND request issued from any processor with a causal dependency on the target address being invalidated by the snoop machine 311 associated with the instance of causality resolution logic 379 is retried.
- causality resolution logic 379 In a large SMP, however, such an embodiment can be prohibitive in cost and many implementations of causality resolution logic 379 only precisely track causal dependency chains of a certain fixed depth (e.g., two or three processors) and in the presence of longer dependency chains resort to pessimistically retrying all TEND requests until the cache line invalidations necessitated by the store instruction have completed processing.
- causality resolution logic is utilized to detect the occurrence of causal dependency chains, to a depth determined by the embodiment, on a pending store that has not completed processing throughout the entire distributed shared memory system.
- causal dependencies are utilized to stall the completion of TEND requests from those processor cores with a causal dependency on the incomplete (pending) stores. In this manner, the memory transaction cannot complete (and therefore make its own stores visible), until the stores the memory transaction has read (i.e., those in the causal dependency chain of the memory transaction) have first completed throughout the distributed shared memory system.
- additional causality resolution logic may be required to ensure the causality of memory operations.
- additional causality resolution logic may be required to ensure the causality of memory operations.
- different threads i.e., logically different processor cores from the point of view of software
- the tend instruction must act as a barrier for transactional stores in the given thread.
- the tend instruction must act as a barrier for non-transactional stores that have been (or may have been) read by transactional loads within the transaction. In the simplest (and most common embodiment), all non-transactional stores within the shared store queue are treated as if they have come from a single thread for purposes of retrying the TEND request.
- snoop machines 311 treat all stores coming from a given multithreaded processor core in a unified manner and will retry any TEND request, as necessary, from that given multithreaded processor core regardless of thread.
- causality resolution logic 379 is not involved in monitoring these intra-core dependencies, but instead is utilized solely to manage causality dependencies between multithreaded processor cores.
- FIG. 8 there is depicted a high level logical flowchart of the processing of a tend instruction terminating a memory transaction in accordance with one embodiment.
- the process begins at block 800 , for example, in response to initiation of execution of a tend instruction within the LSU 202 of a processor core 200 .
- the process of FIG. 8 proceeds from block 800 to block 802 , which depicts ensuring that the cache line invalidations necessitated by transactional stores within the memory transaction have been fully propagated throughout the distributed shared memory system.
- step 804 illustrates ensuring that the cache line invalidations necessitated by causally dependent non-transactional stores have completely propagated throughout the distributed shared memory system.
- verification of propagation of the cache line invalidations necessitated by non-transactional stores is accomplished by one or more instances of causality resolution logic 379 providing a retry response to any applicable TEND request on local interconnect 114 until the previous memory updates of causally dependent non-transactional stores have invalidated all cached copies of the memory location(s) targeted by the memory updates.
- transactional control logic 382 determines whether or not a conflict has occurred for the memory transaction. In response to transactional control logic 382 determining that a conflict has occurred, the process proceeds to block 808 , which depicts transactional control logic 382 invalidating the tentative store footprint of the memory transaction (e.g., as recorded in L2 cache 230 ) and indicating via pass/fail indication 384 that the memory transaction has failed. As further illustrated at block 808 , in response to pass/fail indication 384 processor core 200 updates its condition code register and transfers control to the fail handling branch instruction within the memory transaction (block 808 ). The process then terminates at step 812 .
- step 810 depicts TM control logic 382 committing the transaction, inter alia, by causing the transaction footprint to be committed to the distributed shared memory system (e.g., by updating one or more coherence states in the directory 308 of L2 cache 230 to indicate the transaction footprint is valid and available for access by all threads) and indicating to processor core 200 via pass/fail indication 384 that the memory transaction passed.
- the process then terminates at block 812 .
- Design flow 900 includes processes, machines and/or mechanisms for processing design structures or devices to generate logically or otherwise functionally equivalent representations of the design structures and/or devices described above and shown in FIGS. 1-3 and 7 .
- the design structures processed and/or generated by design flow 900 may be encoded on machine-readable transmission or storage media to include data and/or instructions that when executed or otherwise processed on a data processing system generate a logically, structurally, mechanically, or otherwise functionally equivalent representation of hardware components, circuits, devices, or systems.
- Machines include, but are not limited to, any machine used in an IC design process, such as designing, manufacturing, or simulating a circuit, component, device, or system.
- machines may include: lithography machines, machines and/or equipment for generating masks (e.g. e-beam writers), computers or equipment for simulating design structures, any apparatus used in the manufacturing or test process, or any machines for programming functionally equivalent representations of the design structures into any medium (e.g. a machine for programming a programmable gate array).
- Design flow 900 may vary depending on the type of representation being designed. For example, a design flow 900 for building an application specific IC (ASIC) may differ from a design flow 900 for designing a standard component or from a design flow 900 for instantiating the design into a programmable array, for example a programmable gate array (PGA) or a field programmable gate array (FPGA) offered by Altera® Inc. or Xilinx® Inc.
- ASIC application specific IC
- PGA programmable gate array
- FPGA field programmable gate array
- FIG. 9 illustrates multiple such design structures including an input design structure 1020 that is preferably processed by a design process 910 .
- Design structure 920 may be a logical simulation design structure generated and processed by design process 910 to produce a logically equivalent functional representation of a hardware device.
- Design structure 920 may also or alternatively comprise data and/or program instructions that when processed by design process 910 , generate a functional representation of the physical structure of a hardware device. Whether representing functional and/or structural design features, design structure 920 may be generated using electronic computer-aided design (ECAD) such as implemented by a core developer/designer.
- ECAD electronic computer-aided design
- design structure 920 When encoded on a machine-readable data transmission, gate array, or storage medium, design structure 920 may be accessed and processed by one or more hardware and/or software modules within design process 910 to simulate or otherwise functionally represent an electronic component, circuit, electronic or logic module, apparatus, device, or system such as those shown in FIGS. 1-3 and 7 .
- design structure 920 may comprise files or other data structures including human and/or machine-readable source code, compiled structures, and computer-executable code structures that when processed by a design or simulation data processing system, functionally simulate or otherwise represent circuits or other levels of hardware logic design.
- Such data structures may include hardware-description language (HDL) design entities or other data structures conforming to and/or compatible with lower-level HDL design languages such as Verilog and VHDL, and/or higher level design languages such as C or C++.
- HDL hardware-description language
- Design process 910 preferably employs and incorporates hardware and/or software modules for synthesizing, translating, or otherwise processing a design/simulation functional equivalent of the components, circuits, devices, or logic structures shown in FIGS. 1-3 and 7 to generate a netlist 980 which may contain design structures such as design structure 920 .
- Netlist 980 may comprise, for example, compiled or otherwise processed data structures representing a list of wires, discrete components, logic gates, control circuits, I/O devices, models, etc. that describes the connections to other elements and circuits in an integrated circuit design.
- Netlist 980 may be synthesized using an iterative process in which netlist 980 is resynthesized one or more times depending on design specifications and parameters for the device.
- netlist 980 may be recorded on a machine-readable storage medium or programmed into a programmable gate array.
- the medium may be a non-volatile storage medium such as a magnetic or optical disk drive, a programmable gate array, a compact flash, or other flash memory. Additionally, or in the alternative, the medium may be a system or cache memory, or buffer space.
- Design process 910 may include hardware and software modules for processing a variety of input data structure types including netlist 980 .
- data structure types may reside, for example, within library elements 930 and include a set of commonly used elements, circuits, and devices, including models, layouts, and symbolic representations, for a given manufacturing technology (e.g., different technology nodes, 32 nm, 45 nm, 90 nm, etc.).
- the data structure types may further include design specifications 940 , characterization data 950 , verification data 960 , design rules 970 , and test data files 985 which may include input test patterns, output test results, and other testing information.
- Design process 910 may further include, for example, standard mechanical design processes such as stress analysis, thermal analysis, mechanical event simulation, process simulation for operations such as casting, molding, and die press forming, etc.
- standard mechanical design processes such as stress analysis, thermal analysis, mechanical event simulation, process simulation for operations such as casting, molding, and die press forming, etc.
- One of ordinary skill in the art of mechanical design can appreciate the extent of possible mechanical design tools and applications used in design process 910 without deviating from the scope and spirit of the invention.
- Design process 910 may also include modules for performing standard circuit design processes such as timing analysis, verification, design rule checking, place and route operations, etc.
- Design process 910 employs and incorporates logic and physical design tools such as HDL compilers and simulation model build tools to process design structure 920 together with some or all of the depicted supporting data structures along with any additional mechanical design or data (if applicable), to generate a second design structure 990 .
- Design structure 990 resides on a storage medium or programmable gate array in a data format used for the exchange of data of mechanical devices and structures (e.g., information stored in a IGES, DXF, Parasolid XT, JT, DRG, or any other suitable format for storing or rendering such mechanical design structures).
- design structure 990 preferably comprises one or more files, data structures, or other computer-encoded data or instructions that reside on transmission or data storage media and that when processed by an ECAD system generate a logically or otherwise functionally equivalent form of one or more of the embodiments of the invention shown in FIGS. 1-3 and 7 .
- design structure 990 may comprise a compiled, executable HDL simulation model that functionally simulates the devices shown in FIGS. 1-3 and 7 .
- Design structure 990 may also employ a data format used for the exchange of layout data of integrated circuits and/or symbolic data format (e.g., information stored in a GDSII (GDS2), GL1, OASIS, map files, or any other suitable format for storing such design data structures).
- Design structure 990 may comprise information such as, for example, symbolic data, map files, test data files, design content files, manufacturing data, layout parameters, wires, levels of metal, vias, shapes, data for routing through the manufacturing line, and any other data required by a manufacturer or other designer/developer to produce a device or structure as described above and shown in FIGS. 1-3 and 7 .
- Design structure 990 may then proceed to a stage 995 where, for example, design structure 990 : proceeds to tape-out, is released to manufacturing, is released to a mask house, is sent to another design house, is sent back to the customer, etc.
- a data processing system implements a weak consistency memory model for a distributed shared memory system.
- the data processing system concurrently executes, on a plurality of processor cores, one or more transactional memory instructions within a memory transaction and one or more non-transactional memory instructions.
- the one or more non-transactional memory instructions include a non-transactional store instruction.
- the data processing system commits the memory transaction to the distributed shared memory system only in response to enforcement of causality of the non-transactional store instruction with respect to the memory transaction.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Abstract
A data processing system implements a weak consistency memory model for a distributed shared memory system. The data processing system concurrently executes, on a plurality of processor cores, one or more transactional memory instructions within a memory transaction and one or more non-transactional memory instructions. The one or more non-transactional memory instructions include a non-transactional store instruction. The data processing system commits the memory transaction to the distributed shared memory system only in response to enforcement of causality of the non-transactional store instruction with respect to the memory transaction.
Description
- This application is a continuation of U.S. patent application Ser. No. 13/543,325 entitled “ENSURING CAUSALITY OF TRANSACTIONAL STORAGE ACCESSES INTERACTING WITH NON-TRANSACTIONAL STORAGE ACCESSES,” filed on Jul. 6, 2012, the disclosure of which is incorporated herein by reference in its entirety for all purposes.
- The present invention relates generally to data processing and, in particular, to storage accesses to the shared distributed memory system of a data processing system. Still more particularly, the present invention relates to ensuring causality of transactional storage accesses interacting with non-transactional storage accesses.
- A conventional multiprocessor (MP) computer system, such as a server computer system, includes multiple processing units all coupled to a system interconnect, which typically comprises one or more address, data and control buses. Coupled to the system interconnect is a system memory, which represents the lowest level of volatile memory in the multiprocessor computer system and which generally is accessible for read and write access by all processing units. In order to reduce access latency to instructions and data residing in the system memory, each processing unit is typically further supported by a respective multi-level cache hierarchy, the lower level(s) of which may be shared by one or more processor cores.
- Cache memories are commonly utilized to temporarily buffer memory blocks that might be accessed by a processor in order to speed up processing by reducing access latency introduced by having to load needed data and instructions from system memory. In some MP systems, the cache hierarchy includes at least two levels. The level one (L1) or upper-level cache is usually a private cache associated with a particular processor core and cannot be accessed by other cores in an MP system. Typically, in response to a memory access instruction such as a load or store instruction, the processor core first accesses the directory of the upper-level cache. If the requested memory block is not found in the upper-level cache, the processor core then accesses lower-level caches (e.g., level two (L2) or level three (L3) caches) or system memory for the requested memory block. The lowest level cache (e.g., L3 cache) is often shared among several processor cores.
- In such systems, multiprocessor software concurrently accesses shared data structures from multiple software threads. When concurrently accessing shared data it is typically necessary to prevent so-called “unconstrained races” or “conflicts”. A conflict occurs between two memory accesses when they are to the same memory location and at least one of them is a write and there is no means to ensure the ordering in which those accesses occur.
- Multiprocessor software typically utilizes lock variables to coordinate the concurrent reading and modifying of locations in memory in an orderly conflict-free fashion. A lock variable is a location in memory that is read and then set to a certain value, possibly based on the value read, in an atomic fashion. The read-modify-write operation on a lock variable is often accomplished utilizing an atomic-read-modify-write (ARMW) instruction or by a sequence of instructions that provide the same effect as a single instruction that atomically reads and modifies the lock variable.
- In this manner, a software thread reading an initial “unlocked” value via an ARMW instruction is said to have “acquired” the lock and will, until it releases the lock, be the only software thread that holds the lock. The thread holding the lock may safely update the shared memory locations protected by the lock without conflict with other threads because the other threads cannot obtain the lock until the current thread releases the lock. When the shared locations have been read and/or modified appropriately, the thread holding the lock releases the lock (e.g., by writing the lock variable to the “unlocked” value) to allow other threads to access the shared locations in storage.
- While locking coordinates competing threads' accesses to shared data, locking suffers from a number of well known shortcomings. These include, among others, (1) the possibility of deadlock when a given thread holds more than one lock and prevents the forward progress of other threads and (2) the performance cost of lock acquisition when the lock may not have been strictly necessary because no conflicting accesses would have occurred to the shared data.
- To overcome these limitations, the notion of transactional memory can be employed. In transactional memory, a set of load and/or store instructions are treated as a “transaction.” A transaction succeeds when the constituent load and store operations can occur atomically without a conflict with another thread. The transaction fails in the presence of a conflict with another thread and can then be re-attempted. If a transaction continues to fail, software may fall back to using locking to ensure the orderly access of shared data.
- To support transactional memory, the underlying hardware tracks the storage locations involved in the transaction—the transaction footprint—as the transaction executes for conflicts. If a conflict occurs in the transaction footprint, the transaction is aborted and possibly restarted. Use of transactional memory reduces the possibility of deadlock due to a thread holding multiple locks because, in the typical case, no locks are held (the transaction simply attempts to make one or more storage accesses and restarts if a conflict occurs). Further, the processing overhead of acquiring a lock is generally avoided.
- A data processing system implements a weak consistency memory model for a distributed shared memory system. The data processing system concurrently executes, on a plurality of processor cores, one or more transactional memory instructions within a memory transaction and one or more non-transactional memory instructions. The one or more non-transactional memory instructions include a non-transactional store instruction. The data processing system commits the memory transaction to the distributed shared memory system only in response to enforcement of causality of the non-transactional store instruction with respect to the memory transaction.
-
FIG. 1 is a high-level block diagram of an exemplary data processing system in accordance with one embodiment; -
FIG. 2 is a more detailed block diagram of an exemplary processing unit in accordance with one embodiment; -
FIG. 3 is a detailed block diagram of lower level cache supporting memory transactions in accordance with one embodiment; -
FIG. 4 is an illustrative example of a memory transaction in accordance with one embodiment; -
FIG. 5 is an illustrative example of a memory transaction including a suspend region in accordance with one embodiment; -
FIG. 6A depicts execution of an exemplary program illustrating causality in a multiprocessor data processing system; -
FIG. 6B illustrates execution of an exemplary program including memory transactions to ensure causality; -
FIG. 6C depicts execution of an exemplary program including both transactional and non-transactional memory accesses; -
FIG. 7 illustrates a multiprocessor data processing system including at least three processor cores that execute the exemplary program ofFIG. 6C ; -
FIG. 8 is a high level logical flowchart of an exemplary method by which a multiprocessor data processing system ensures causality in execution of a program including both transactional and non-transactional memory accesses; and -
FIG. 9 is a data flow diagram illustrating a design process. - With reference now to the figures, wherein like reference numerals refer to like and corresponding parts throughout, and in particular with reference to
FIG. 1 , there is illustrated a high-level block diagram depicting an exemplarydata processing system 100 in accordance with one embodiment. In the depicted embodiment,data processing system 100 is a cache coherent symmetric multiprocessor (SMP) data processing system includingmultiple processing nodes system interconnect 110 for conveying address, data and control information.System interconnect 110 may be implemented, for example, as a bused interconnect, a switched interconnect or a hybrid interconnect. - In the depicted embodiment, each processing node 102 is realized as a multi-chip module (MCM) containing four
processing units 104 a-104 d, each preferably realized as a respective integrated circuit. Theprocessing units 104 within each processing node 102 are coupled for communication to each other and system interconnect 110 by alocal interconnect 114, which, like system interconnect 110, may be implemented, for example, with one or more buses and/or switches. System interconnect 110 andlocal interconnects 114 together form a system fabric. - As described below in greater detail with reference to
FIG. 2 ,processing units 104 each include amemory controller 106 coupled tolocal interconnect 114 to provide an interface to arespective system memory 108. Data and instructions residing insystem memories 108 can generally be accessed, cached and modified by a processor core in anyprocessing unit 104 of any processing node 102 withindata processing system 100.System memories 108 thus form the lowest level of volatile storage in the distributed shared memory system ofdata processing system 100. In alternative embodiments, one or more memory controllers 106 (and system memories 108) can be coupled to system interconnect 110 rather than alocal interconnect 114. - Those skilled in the art will appreciate that SMP
data processing system 100 ofFIG. 1 can include many additional non-illustrated components, such as interconnect bridges, non-volatile storage, ports for connection to networks or attached devices, etc. Because such additional components are not necessary for an understanding of the described embodiments, they are not illustrated inFIG. 1 or discussed further herein. It should also be understood, however, that the enhancements described herein are applicable to cache coherent data processing systems of diverse architectures and are in no way limited to the generalized data processing system architecture illustrated inFIG. 1 . - Multiprocessor data processing system such as
data processing system 100 ofFIG. 1 implement a memory consistency model that specifies the legal possible executions of a given multiprocessor program with respect to memory accesses (e.g., among other things, the values that may be returned by load instructions, the order of writes to memory, those instruction execution dependencies that affect the ordering of memory accesses, and the final values for memory locations at the conclusion of a multiprocessor program). A memory consistency model is specified by two major characteristics: ordering of memory access operations and atomicity of store operations. - The ordering of memory operations specifies how memory operations may, if at all, be re-ordered relative to the order of their respective load and store instructions in the individual threads of execution in the multiprocessor program. There are four general ordering cases: (1) ordering of the memory operations for a load instruction to a following load instruction, (2) ordering of the memory operations for a load instruction to a following store instruction, (3) ordering of the memory operations for a store instruction to a following store instruction, and (4) ordering of the memory operations for a store instruction to a following load instruction. Strong consistency memory models will, in general, preserve all or at least most of these orderings. In particular, many strong consistency memory models enforce the first three orderings, but do not enforce store-to-load ordering. Weak consistency memory models will generally not enforce most or all of these orderings.
- Atomicity of store operations refers to whether or not a given thread of execution can read the value of its own store operation before other threads, and furthermore, whether the value written to the distributed shared memory system by the store operation becomes visible to other threads in a logically instantaneous fashion or whether the value can become visible to other threads at different points in time. A memory consistency model is called “multi-copy atomic” if the value written by a store operation of one thread becomes visible to all other threads in a logically instantaneous fashion. In general, strong consistency memory models are multi-copy atomic, and weak consistency memory models do not enforce multi-copy atomicity.
- In a given multiprocessor program, program semantics often require that multi-copy atomicity and/or the various orderings between memory access operations are respected. Therefore, in a
data processing system 100 that implements a weak consistency memory model, so called “barrier” (e.g., SYNC) instructions are typically provided to allow the programmer to specify what memory access operation orderings and atomicity are to be applied during execution of the multiprocessor program. - Referring now to
FIG. 2 , there is depicted a more detailed block diagram of anexemplary processing unit 104 in accordance with one embodiment. In the depicted embodiment, eachprocessing unit 104 is an integrated circuit including two ormore processor cores processor core 200 is capable of independently executing multiple hardware threads of execution simultaneously. As depicted, eachprocessor core 200 includes one or more execution units, such as load-store unit (LSU) 202, for executing instructions. The instructions executed byLSU 202 include memory access instructions that request load or store access to a memory block in the distributed shared memory system or cause the generation of a request for load or store access to a memory block in the distributed shared memory system. Memory blocks obtained from the distributed shared memory system by load accesses are buffered in one or more register files (RFs) 208, and memory blocks are written to the distributed shared memory system from the one or more register files 208. - The operation of each
processor core 200 is supported by a multi-level volatile memory hierarchy having at its lowest level a sharedsystem memory 108 accessed via anintegrated memory controller 106, and at its upper levels, one or more levels of cache memory, which in the illustrative embodiment include a store-through level one (L1)cache 226 within and private to eachprocessor core 200, and a respective store-in level two (L2)cache 230 for eachprocessor core L2 cache 230 can be implemented with multiple L2 cache slices, each of which handles memory access requests for a respective set of real memory addresses. - Although the illustrated cache hierarchies includes only two levels of cache, those skilled in the art will appreciate that alternative embodiments may include additional levels (L3, L4, etc.) of on-chip or off-chip, private or shared, in-line or lookaside cache, which may be fully inclusive, partially inclusive, or non-inclusive of the contents the upper levels of cache.
- Each
processing unit 104 further includes an integrated and distributedfabric controller 216 responsible for controlling the flow of operations on the system fabric comprisinglocal interconnect 114 andsystem interconnect 110 and for implementing the coherency communication required to implement the selected cache coherency protocol.Processing unit 104 further includes an integrated I/O (input/output)controller 214 supporting the attachment of one or more I/O devices (not depicted). - In operation, when a hardware thread under execution by a
processor core 200 includes a memory access instruction requesting a specified memory access operation to be performed,LSU 202 executes the memory access instruction to determine the target address of the memory access request. After translation of the target address to a real address,L1 cache 226 is accessed utilizing the target address. Assuming the indicated memory access cannot be satisfied solely by reference toL1 cache 226,LSU 202 then transmits the memory access request, which includes at least a transaction type (ttype) (e.g., load or store) and the target real address, to itsaffiliated L2 cache 230 for servicing. - With reference now to
FIG. 3 , there is illustrated a more detailed block diagram of an exemplary embodiment of a lower level cache (e.g., an L2 cache 230) that supports memory transactions in accordance with one embodiment. As shown inFIG. 3 ,L2 cache 230 includes acache array 302 and adirectory 308 of the contents ofcache array 302. Although not explicitly illustrated,cache array 302 preferably is implemented with a single read port and single write port to reduce the die area required to implementcache array 302. - Assuming
cache array 302 anddirectory 308 are set associative as is conventional, memory locations insystem memories 108 are mapped to particular congruence classes withincache array 302 utilizing predetermined index bits within the system memory (real) addresses. The particular memory blocks stored within the cache lines ofcache array 302 are recorded incache directory 308, which contains one directory entry for each cache line. While not expressly depicted inFIG. 3 , it will be understood by those skilled in the art that each directory entry incache directory 308 includes various fields, for example, a tag field that identifies the real address of the memory block held in the corresponding cache line ofcache array 302, a state field that indicate the coherency state of the cache line, an LRU (Least Recently Used) field indicating a replacement order for the cache line with respect to other cache lines in the same congruence class, and inclusivity bits indicating whether the memory block is held in the associatedL1 cache 226. -
L2 cache 230 includes multiple (e.g., 16) Read-Claim (RC)machines 312 for independently and concurrently servicing load (LD) and store (ST) requests received from the affiliatedprocessor core 200. In order to service remote memory access requests originating fromprocessor cores 200 other than the affiliatedprocessor core 200,L2 cache 230 also includes multiple snoop machines 311. Each snoop machine 311 can independently and concurrently handle a remote memory access request “snooped” fromlocal interconnect 114. As will be appreciated, the servicing of memory access requests byRC machines 312 may require the replacement or invalidation of memory blocks withincache array 302. Accordingly,L2 cache 230 includes CO (castout)machines 310 that manage the removal and writeback of memory blocks fromcache array 302. -
L2 cache 230 further includes anarbiter 305 that controls multiplexers M1-M2 to order the processing of local memory access requests received fromaffiliated processor core 200 and remote requests snooped onlocal interconnect 114. Memory access requests, including local and remote load and store operations, are forwarded in accordance with the arbitration policy implemented byarbiter 305 to dispatch logic, such as adispatch pipeline 306, which processes each read/load and store request with respect todirectory 308 andcache array 302. As described further below, transactional memory (TM)logic 380 tracks memory access operations within memory transactions to ensure completion of the memory access operations in an atomic manner or to abort the memory transactions in the presence of conflicts. -
L2 cache 230 also includes anRC queue 320 and a CPI (castout push intervention)queue 318 that respectively buffer data being inserted into and removed from thecache array 302.RC queue 320 includes a number of buffer entries that each individually correspond to a particular one ofRC machines 312 such that eachRC machine 312 that is dispatched retrieves data from only the designated buffer entry. Similarly,CPI queue 318 includes a number of buffer entries that each individually correspond to a particular one of thecastout machines 310 and snoop machines 311, such that eachCO machine 310 and each snooper 311 that is dispatched retrieves data from only the respective designated CPI buffer entry. - Each
RC machine 312 also has assigned to it a respective one of multiple RC data (RCDAT) buffers 322 for buffering a memory block read fromcache array 302 and/or received fromlocal interconnect 114 via reloadbus 323. TheRCDAT buffer 322 assigned to eachRC machine 312 is preferably constructed with connections and functionality corresponding to the memory access requests that may be serviced by the associatedRC machine 312. RCDAT buffers 322 have an associated store data multiplexer M4 that selects data bytes from among its inputs for buffering in theRCDAT buffer 322 in response unillustrated select signals generated byarbiter 305. - In operation, a
processor core 200 transmits store requests comprising a transaction type (ttype), target real address and store data to a store queue (STQ) 304. FromSTQ 304, the store data are transmitted to store data multiplexer M4 viadata path 324, and the transaction type and target address are passed to multiplexer M1. Multiplexer M1 also receives as inputs processor load requests fromprocessor core 200 and directory write requests fromRC machines 312. In response to unillustrated select signals generated byarbiter 305, multiplexer M1 selects one of its input requests to forward to multiplexer M2, which additionally receives as an input a remote request received fromlocal interconnect 114 viaremote request path 326.Arbiter 305 schedules local and remote memory access requests for processing and, based upon the scheduling, generates a sequence of select signals 328. In response to selectsignals 328 generated byarbiter 305, multiplexer M2 selects either the local request received from multiplexer M1 or the remote request snooped fromlocal interconnect 114 as the next memory access request to be processed. - The request selected for processing by
arbiter 305 is placed by multiplexer M2 intodispatch pipeline 306.Dispatch pipeline 306 preferably is implemented as a fixed duration pipeline in which each of multiple possible overlapping requests is processed for a predetermined number of clock cycles (e.g., 4 cycles). During the first cycle of processing withindispatch pipeline 306, a directory read is performed utilizing the request address to determine if the request address hits or misses indirectory 308, and if the memory address hits, the coherency state of the target memory block. The directory information, which includes a hit/miss indication and the coherency state of the memory block, is returned bydirectory 308 to dispatchpipeline 306 in a subsequent cycle. As will be appreciated, no action is generally taken within anL2 cache 230 in response to miss on a remote memory access request; such remote memory requests are accordingly discarded fromdispatch pipeline 306. However, in the event of a hit or miss on a local memory access request or a hit on a remote memory access request,L2 cache 230 will service the memory access request, which for requests that cannot be serviced entirely withinprocessing unit 104, may entail communication onlocal interconnect 114 viafabric controller 216. - At a predetermined time during processing of the memory access request within
dispatch pipeline 306,arbiter 305 transmits the request address tocache array 302 via address andcontrol path 330 to initiate a cache read 402 of the memory block specified by the request address. The memory block read fromcache array 302 is transmitted viadata path 342 to Error Correcting Code (ECC)logic 344, which checks the memory block for errors and, if possible, corrects any detected errors. For processor load requests, the memory block is also transmitted to load data multiplexer M3 viadata path 340 for forwarding to the affiliatedprocessor core 200. - At the last cycle of the processing of a memory access request within
dispatch pipeline 306,dispatch pipeline 306 makes a dispatch determination based upon a number of criteria, including (1) the presence of an address collision between the request address and a previous request address currently being processed by acastout machine 310, snoop machine 311 orRC machine 312, (2) the directory information, and (3) availability of anRC machine 312 or snoop machine 311 to process the memory access request. Ifdispatch pipeline 306 makes a dispatch determination that the memory access request is to be dispatched, the memory access request is dispatched fromdispatch pipeline 306 to anRC machine 312 or a snoop machine 311. If the memory access request fails dispatch, the failure is signaled to the requestor (e.g., local or remote processor core 200) by a retry response. The requestor may subsequently retry the failed memory access request, if necessary. - While an
RC machine 312 is processing a local memory access request, theRC machine 312 has a busy status and is not available to service another request. While anRC machine 312 has a busy status, theRC machine 312 may perform a directory write to update the relevant entry ofdirectory 308, if necessary. In addition, theRC machine 312 may perform a cache write to update the relevant cache line ofcache array 302. Directory writes 408 a, 408 b and cache writes may be scheduled byarbiter 305 during any interval in which dispatchpipeline 306 is not already processing other requests according to the fixed scheduling of directory reads and cache reads. When all operations for the given request have been completed, theRC machine 312 returns to an unbusy state. - Associated with
RC machines 312 is data handling circuitry, different portions of which are employed during the servicing of various types of local memory access requests. For example, for a local load request that hits indirectory 308, an uncorrected copy of the target memory block is forwarded fromcache array 302 to the affiliatedprocessor core 200 viadata path 340 and load data multiplexer M3 and additionally forwarded toECC logic 344 viadata path 342. In the case of an ECC error in the target memory block obtained by the local load request, corrected data is forwarded toRCDAT buffer 322 viadata path 346 and store data multiplexer M4 and then fromRCDAT 322 to affiliatedprocessor core 200 viadata path 360 and load data multiplexer M3. For a local store request, store data is received withinRCDAT buffer 322 fromSTQ 304 viadata path 324 and store data multiplexer M4, the store is merged with the memory block read intoRCDAT buffer 322 fromcache array 302 viaECC logic 344 and store data multiplexer M4, and the merged store data is then written fromRCDAT buffer 322 intocache array 302 viadata path 362. In response to a local load miss or local store miss, the target memory block acquired through issuing a memory access operation onlocal interconnect 114 is loaded intocache array 302 via reloadbus 323, store data multiplexer M4, RCDAT buffer 322 (with store merge for a store miss) anddata path 362. - Referring now to
FIG. 4 , an illustrative example of a memory transaction is depicted. Those skilled in the art will recognize that the particular semantics and instructions utilized to implement a memory transaction are but one possible implementation and that the disclosed techniques of implementing transactional memory are not dependent on the specific instructions and instruction semantics employed. -
Illustrative memory transaction 400 begins attbegin instruction 402. Thetbegin instruction 402 initiates the memory transaction, causes theprocessor core 200 executingtbegin instruction 402 to take acheckpoint 210 of the architected register state ofprocessor core 200, and invokes tracking of load and store instructions within thetransaction body 406 to ensure they complete in an atomic fashion or thatmemory transaction 400 fails in the presence of a conflict.Memory transaction 400 additionally includes abranch instruction 404 immediately followingtbegin instruction 402. Whenmemory transaction 400 first executes, the condition code register upon whichbranch instruction 404 depends is initialized to a value that causes the program branch indicated bybranch instruction 404 not to be taken and the flow of execution to continue totransaction body 406. As discussed below, in response to failure ofmemory transaction 400, the condition code register is set to a different value, andbranch instruction 404 causes execution to branch to a fail handler. - In the exemplary embodiment depicted in
FIG. 3 ,TM logic 380 tracks memory access (e.g., load and store) instructions withintransaction body 406 to ensure that they complete in an atomic fashion or thatmemory transaction 400 fails in the presence of a conflict. In particular,TM tracking logic 381 includes a number of entries that indicate which cache lines incache array 302 are included in the transaction footprint. The transaction footprint includes two portions: the load footprint corresponding to cache lines touched solely by loads within transaction body 406 (e.g., the cache line at address A in exemplary memory transaction 400) and the store footprint corresponding to cache lines touched solely by store instructions or by both load and store instructions in transaction body 406 (e.g., the cache line at address B in exemplary memory transaction 400). - As further shown in
FIG. 3 ,TM logic 380 further includestransactional control logic 382, which controls the sequencing of a memory transaction and provides a pass/fail indication 384 and an optional TM killedindication 385 to the associatedprocessor core 200. Pass/fail indication 384 indicates toprocessor core 200 whether or not the memory transaction successfully committed at the execution of the tendinstruction 408 at the end ofmemory transaction 400. TM killindication 385 indicates toprocessor core 200 whether or not a conflict has occurred during the transaction. In response totransactional control logic 382 assertingTM kill indication 385,processor core 200 may, as a performance optimization, optionally abort and restartmemory transaction 400 prior to reaching tendinstruction 408. - In response to pass/fail indication 384 (or optionally TM kill indication 385) indicating that a conflict has occurred during execution of
memory transaction 400,processor core 200 re-establishes its architected register state from thecheckpoint 210 taken at the execution oftbegin instruction 402, invalidates the tentatively modified cache lines in the store footprint, releases trackinglogic 381, sets the condition code register such thatbranch instruction 404 will be taken, and transfers control tobranch instruction 404. In addition,processor core 200 sets a transaction failure cause register (not shown) inprocessor core 200 to indicate the cause of the transaction's failure. The fail handler routine invoked bybranch instruction 404 may choose to re-attemptmemory transaction 400 or fall back to more conventional locking mechanisms, optionally based on the content of the transaction failure cause register. - During the execution of a memory transaction, the values stored to the distributed shared memory system by transaction body 406 (i.e., those in the store footprint of the memory transaction) are visible only to the thread of the
processor core 200 executing the memory transaction. Threads running on the same orother processor cores 200 will not see these values until and only if the memory transaction successfully commits. - For a memory transaction to successfully commit, the load and store instructions in
transaction body 406 must complete in an atomic fashion (i.e., there must be no conflicts for the cache lines in the transaction load and store footprints) and the effects of the store instructions intransaction body 406 must propagate to all processingunits 104 indata processing system 100 and invalidate any cached copies of those cache lines held inother processing units 104. If both of these conditions hold when tendinstruction 408 is executed,transactional control logic 382 indicates toprocessor core 200 via pass/fail indication 384 thatmemory transaction 400 passed and commits all stores performed intransaction body 406 toL2 cache 230, thus making them visible to all other threads andprocessor cores 200 in the system simultaneously. - In the following discussion, a load or store will be called “transactional” if that load or store instruction occurs within the
transaction body 406 of amemory transaction 400. Similarly, a load or store will be called “non-transactional” if it occurs outside atransaction body 406. In one exemplary embodiment, a conflict policy ofdata processing system 100 defines a conflict with another processor core's memory access to occur for a given memory transaction in any one of several possible cases. In a first case, a conflict occurs if a non-transactional store from anotherprocessor core 200 hits a cache line within either the given memory transaction's load or store footprint. In a second case, a conflict occurs if a transactional store from anotherprocessor core 200 hits a cache line within the given memory transaction's load footprint. In a third case, a conflict occurs if a non-transactional load hits a cache line within the given memory transaction's store footprint. In a fourth case, a conflict occurs if a transactional load from anotherprocessor core 200 hits a cache line within the given memory transaction's store footprint. In addition, the given memory transaction has a conflict if one of its transactional stores hits an address already extant in the store footprint of another processor core's memory transaction. This exemplary conflict policy is but one of several possible embodiments of transactional memory. The above conflict policy biases in favor of transactional stores over transactional loads, while allowing transactional and non-transactional loads to freely intermingle. - With reference now to
FIG. 5 , there is illustrated arepresentative memory transaction 500 containing a suspend region. As can be seen by comparison ofFIGS. 4-5 ,memory transaction 500 includes atbegin instruction 502,branch instruction 504,transaction body 506 and tendinstruction 508, which correspond totbegin instruction 402,branch instruction 404,transaction body 406 and tendinstruction 408 described above. In addition,memory transaction 500 includes atsuspend instruction 510 that initiates the start of a suspendedregion 512. When a memory transaction is suspended through execution oftsuspend instruction 510, the load and store footprints currently established for the enclosing memory transaction containing suspendedregion 512 remain in place and continue to be tracked byTM tracking logic 381 for conflicts. However, any load or store instructions within suspendedregion 512 are treated as non-transactional loads and stores and follow existing semantics for such loads and stores. In particular, stores within suspendedregion 512 are non-transactional and will commit and begin propagating to other processors unconditionally. If a store within suspendedregion 512 hits either the load or the store footprint of the enclosing transaction, a conflict occurs (which also destroys the tentative transactional version of the cache line in the store footprint) and is logged bytransactional control logic 382. However, this conflict is not acted on until the enclosing memory transaction is resumed upon execution oftresume instruction 514, at which point theprocessor core 200 passes control tobranch instruction 504 as described. If a non-transactional load instruction within suspendedregion 512 hits a cache line within the store footprint of the enclosingmemory transaction 500, that load instruction returns the tentatively updated value written by a transactional store within thetransaction body 506 unless that value has been overwritten by a non-transactional store either by anotherprocessor core 200 or by a non-transactional store in suspendedregion 512, in which case the non-transactional load instruction returns the current value of the target location. - Use of a suspended
region 512 allows the temporary suspension of a memory transaction, which permits store instructions in the suspendedregion 512 to unconditionally update locations in the shared distributed memory system while also allowing for the resumption of the memory transaction at a later time. One possible use for a suspendedregion 512 is to log debug information into a scratchpad region of the distributed shared memory system and then to resume the enclosing memory transaction. Without a suspended region, the write of the debug information would be rolled back any time the enclosing memory transaction is aborted. - Referring now to
FIG. 6A , the execution of an exemplary program illustrating the property of causality in a multiprocessor data processing system is shown. As used herein “causality,” which is desirable property in multiprocessor programs, is defined as being preserved if, during execution of a multiprocessor program, a given thread of execution cannot read the effects of a computation before the writes that caused the computation can be read by the given thread. - In the simplified example given in
FIG. 6A (as well as those discussed below with reference toFIGS. 6B-6C ), a multiprocessor program is executed by threeprocessor cores 200 ofdata processing system 100, labeled for ease of reference asprocessor core 0,processor core 1 andprocessor core 2. InFIG. 6A ,processor core 0 executes astore instruction 600 that writes a value of 1 to address A in the shared distributed memory system. This update of address A propagates toprocessor core 1, andload instruction 610 executed byprocessor core 1 therefore returns a value of 1. Even though the memory update made bystore instruction 600 has propagated toprocessor core 1, that memory update may not yet have propagated toprocessor core 2. Ifstore instruction 614 executes onprocessor 1 and the associated memory update propagates toprocessor 2 before the memory update ofstore instruction 600 propagates toprocessor 2, causality would be violated because the store of the value of 1 to address B, which is an effect of the store to address A, would be visible toprocessor core 2 before the memory update associated withcausal store instruction 600 was visible toprocessor core 2. - To ensure causality in a weak consistency memory model, barrier instruction 612 (e.g., a SYNC) ensures that
store instruction 614 does not take effect or begin propagating its memory update to other processor cores untilload instruction 610 has bound to its value. In addition,barrier instruction 612 also ensures that the memory update associated withstore instruction 600 propagates toprocessor 2 before the memory update associated withstore instruction 614. Thus, causality is preserved because the cause of the computation (i.e., the memory update of store instruction 600) is visible toprocessor core 2 before the result of the computation (i.e., the memory update of store 614). Abarrier instruction 622 is also executed byprocessor core 2 to ensure thatprocessor core 2 executesload instructions processor core 2 properly observes the memory updates made byprocessor core 0 andprocessor core 1. - With reference now to
FIG. 6B , an exemplary embodiment of the multiprocessor program ofFIG. 6A rendered in terms of memory transactions is illustrated. InFIG. 6B , the branch instructions to the memory transaction fail handler are omitted for clarity. - As illustrated,
processor core 0 executes amemory transaction 630 including atbegin instruction 632, tendinstruction 636, and a transaction body including astore instruction 634 that stores a value of 1 to address A. Upon the execution of tendinstruction 636,memory transaction 600 successfully commits and makes the update to address A visible to all the other processor cores simultaneously. In particular, by thetime load instruction 642 of thememory transaction 640 executing onprocessor core 1 can read the value of 1 from address A,load instruction 654 of thememory transaction 650 executing onprocessor core 2 must also be able to read the value of 1 for addressA. Memory transaction 640 then reads the value of 1 for address A, stores a value of 1 to address B and successfully commits. Finally,load instruction 652 ofmemory transaction 650 reads a value of 1 for address B, and given thatmemory transaction 640 read a value of 1 for A,load instruction 654 must also read a value of 1 for address A. - In order to make the memory updates of store instructions in a successful transaction visible to all other processor cores simultaneously, before that memory transaction can commit all the cache line invalidates necessitated by the memory transaction must have propagated through the data processing system such that any other processor cores' now stale copies of the updated cache lines have been removed (e.g., invalidated) and can no longer be read by the other processor cores. Without this requirement, a processor core could still read a stale value for an updated memory location after the memory transaction that updated the memory location committed. A processor core, therefore, needs to ensure that the memory updates associated with its own transactional stores are fully propagated through the data processing system to invalidate any stale cached copies before committing a successful memory transaction in order to maintain the semantics of memory transactions. As a consequence of the propagation of the memory updates inherent in the semantics of memory transactions, causality is trivially preserved when only memory transactions are utilized to access memory locations in a shared distributed memory system. However, when transactional and non-transactional code interact on the same shared variables, causality is not directly preserved by ensuring that the memory updates made by a transaction are visible simultaneously to all other processor cores.
- Referring now to
FIG. 6C , an illustrative multiprocessor program is depicted that includes a mixture of transactional and non-transactional accesses to a shared distributed memory system. In the exemplary multiprocessor program,processor core 0 executes anon-transactional store instruction 660 that unconditionally writes a value of 1 to address A in the shared distributed memory system. This value propagates toprocessor core 1 and is read bytransactional load instruction 672 within thememory transaction 670 executed byprocessor core 1.Processor core 1 then executes astore instruction 674 withinmemory transaction 670 that updates the cache line associated with address B and completes invalidating any stale cached copies of the cache line associated with address B (so that no other processor core holds a copy of the now stale cache line) and successfully commitsmemory transaction 670 upon execution of tendinstruction 676.Processor core 2 then executesload instructions 680 and 684 to read, in order, the cache lines associated with addresses B and A, respectively, based on the ordering enforced bybarrier instruction 682. Iftransaction 670 only ensures that its own memory updates are fully propagated through the distributed shared memory system before committing, the memory update ofstore instruction 660 may or may not have propagated toprocessor core 2. Therefore, in at least some operating scenarios,processor core 2 could read a value of 1 for the cache line associated with address B and the, now stale, initial value of 0 for the cache line associated with address A, thus violating causality. The same result would be obtained ifprocessor core 2 utilized transactional loads to read from addresses A and B, as depicted forprocessor 2 inFIG. 6B . - To guarantee causality,
memory transaction 670 must ensure not only that its own transactional stores are propagated throughout the entire distributed shared memory system, but also that any non-transactional store that is read by a transactional load within the transaction has also propagated throughout the distributed shared memory system. (Memory updates of transactional writes that are read by the memory transaction are guaranteed to have propagated throughout the distributed shared memory system because those memory updates could not be read bytransaction 670 before they were visible to the entire distributed shared memory system). To ensure that the memory updates of non-transactional stores read bymemory transaction 670 are also propagated throughout the distributed shared memory system, the processing of the tendinstruction 676 ofmemory transaction 670 must not allow commitment ofmemory transaction 670 until the memory update of any non-transactional store read bymemory transaction 670 is propagated throughout the distributed shared memory system. - With reference now to
FIG. 7 , there is illustrated a partial view ofdata processing system 100 ofFIG. 1 , which executes the multiprocessor program ofFIG. 6C . In the view given inFIG. 7 ,processor cores processor cores FIG. 6C . Further, an instance of causality resolution logic 379 is instantiated for and coupled to each instance of snooper 311, for example, as a component of theL2 cache 230 affiliated with eachprocessor core 200. - Initially,
processor core 200 c holds a cached copy of the initial value (e.g., 0) of memory location A in itsL1 cache 226 c.Processor 200 a begins execution of the multiprocessor program ofFIG. 6C by executingstore instruction 660. In response to execution ofstore instruction 660,processor core 200 a transmits a store request to itsL2 cache 230 a, which allocates anRC machine 312 to service the store request.RC machine 312 broadcasts the store request ontolocal interconnect 114, and snoopmachine 311 c of theL2 cache 230 c affiliated withprocessor core 200 c registers the store request, including the processing unit that sourced the store request (i.e., the processing unit includingprocessor core 200 a). At this point, the memory update ofstore instruction 660 has not propagated toprocessor core 200 c, but is instead queued for later processing, advantageously allowingprocessor core 200 a to continue executing further instructions before the memory update ofstore instruction 660 is fully propagated. -
Processor core 200 b then executesload instruction 672 and, finding no copy of the target cache line associated with address A in itsL1 cache 226 b, transmits a read request to itsL2 cache 230 b. In response to the read request,L2 cache 230 b allocatesRC machine 312 b to service the read request. In response to a miss of the read request inL2 cache 230 b,RC machine 312 b issues a read request ontolocal interconnect 114 to obtain the current value for addressA. L2 cache 230 a responds to the read request and provides the current value of address A toprocessor core 200 b by cache-to-cache intervention. At this point a so-called “causality passing read” has occurred, that is,load instruction 672 has read the value of a store instruction that has not fully propagated through the entire distributed shared memory system. To account for this fact and to protect causality,causality resolution logic 379 c inL2 cache 230 c notes the successful read intervention between the vertical cache hierarchies ofprocessor cores machine 311 c. In this mannercausality resolution logic 379 c directly tracks thecausal dependency processor 200 b and its vertical cache hierarchy has on the memory update ofstore instruction 660 completing its propagation. -
Processor 200 b executesstore instruction 674, which specifies an update of the value of address B to 1. In response to execution ofstore instruction 674,RC machine 312 b issues a store request corresponding to storeinstruction 674 onlocal interconnect 114. In absence of an existing cached copy of the target cache line,memory controller 106 supplies the current value of address B fromsystem memory 108 in response to the store request, andRC machine 312 bupdates L2 cache 230 b accordingly. At thispoint processor core 1 executes tendinstruction 676 to attempt to successfully committransaction 670 and places a corresponding TEND request onlocal interconnect 114 to ensure that all prior memory updates by transactional stores inmemory transaction 670 have been propagated throughout the distributed shared memory system and that any memory updates by non-transactional stores read bymemory transaction 670 have similarly propagated throughout the distributed shared memory system. In this case, the memory update ofstore instruction 674 has fully propagated throughout the distributed shared memory system because no other caches held a copy of the cache line associated with address B. However, had any such copy existed and had the memory update not been fully complete, a snoop machine 311 in those caches, which noted theinitial processor core 200 issuing the store, would be active and would retry the snooped TEND request from thatprocessor core 200 until the invalidation of the cached copy of the cache line completes. - In the case at hand, the TEND request is not from the
processor core 200 that initiated the store request, and therefore snoopmachine 311 c will not retry the TEND request. However,causality resolution logic 379 c has a causal dependency forprocessor 200 b and its vertical cache hierarchy and issues on local interconnect 114 a retry response to the TEND request because the TEND request was issued from aprocessor core 200 that was the recipient of a causality passing read of the same address that snoopmachine 311 c is processing. In this manner, causality resolution logic 379 directly tracks whichprocessor cores 200 have a causality dependency due to reading a memory update of a non-transactional store that was not fully completed for the processor core with which causality resolution logic 379 is associated. - It should be noted that, in general, causality resolution logic 379 must maintain a list capable of representing all the
processors core 200 in the data processing system to provide causality in cases in which the causality dependency chain passes through more than one processor core (e.g., a test where a first processor stores a location, a second processor reads that location and then stores a first flag variable, a third processor loads the first flag variable and writes a second flag in a transaction, and then a final thread reads the second flag and then the initial location). In such an implementation, a TEND request issued from any processor with a causal dependency on the target address being invalidated by the snoop machine 311 associated with the instance of causality resolution logic 379 is retried. In a large SMP, however, such an embodiment can be prohibitive in cost and many implementations of causality resolution logic 379 only precisely track causal dependency chains of a certain fixed depth (e.g., two or three processors) and in the presence of longer dependency chains resort to pessimistically retrying all TEND requests until the cache line invalidations necessitated by the store instruction have completed processing. - To summarize, causality resolution logic is utilized to detect the occurrence of causal dependency chains, to a depth determined by the embodiment, on a pending store that has not completed processing throughout the entire distributed shared memory system. These causal dependencies are utilized to stall the completion of TEND requests from those processor cores with a causal dependency on the incomplete (pending) stores. In this manner, the memory transaction cannot complete (and therefore make its own stores visible), until the stores the memory transaction has read (i.e., those in the causal dependency chain of the memory transaction) have first completed throughout the distributed shared memory system. Only after these stores in the memory transaction's causal dependency chain (and the transactional stores of the memory transaction itself, though this is guaranteed by snooper 311 instead of causality resolution logic 379) have completed, may the TEND request complete, leading to the memory transaction successfully committing if no conflicts have occurred during its execution.
- In other embodiments, additional causality resolution logic may be required to ensure the causality of memory operations. For example, in an implementation that contains a write-through L1 cache shared by a multithreaded processor core followed by a shared L2 store queue, it is possible for different threads (i.e., logically different processor cores from the point of view of software) to read stored values from the L1 cache before these stores have even propagated to the L2 cache, much less to the entire distributed shared memory system. In such an implementation, the tend instruction must act as a barrier for transactional stores in the given thread. This behavior ensures that the transactional stores are propagated to the system interconnect and the necessary snoop machines 311 so that the tend instruction can ensure, when trying to complete the memory transaction, that all of the cache line invalidations required by the memory transaction's stores have fully propagated. In addition, the tend instruction must act as a barrier for non-transactional stores that have been (or may have been) read by transactional loads within the transaction. In the simplest (and most common embodiment), all non-transactional stores within the shared store queue are treated as if they have come from a single thread for purposes of retrying the TEND request.
- In this manner, all non-transactional stores from which any transaction has (or may have) read that have not been fully propagated are broadcast to snoop machines 311 as necessary before a TEND request for any transaction from that multithreaded processor core is presented on
local interconnect 114. In such an embodiment, snoop machines 311 treat all stores coming from a given multithreaded processor core in a unified manner and will retry any TEND request, as necessary, from that given multithreaded processor core regardless of thread. In this embodiment, causality resolution logic 379 is not involved in monitoring these intra-core dependencies, but instead is utilized solely to manage causality dependencies between multithreaded processor cores. - The exact placement and details of the necessary causality resolution logic will vary with the particulars of given embodiment and will be apparent to those skilled in the art given the teachings herein. In general, at any point where a load may return the value of a store that has not fully propagated throughout the entire distributed shared memory system, a mechanism must be provided to ensure that any store with a causal dependency to a different processor core is noted and that causal dependency delays the processing of a tend instruction (or other semantic) ending a memory transaction until such time as the stores in the causal dependency chain of the memory transaction have completed propagating.
- Referring now to
FIG. 8 , there is depicted a high level logical flowchart of the processing of a tend instruction terminating a memory transaction in accordance with one embodiment. The process begins atblock 800, for example, in response to initiation of execution of a tend instruction within theLSU 202 of aprocessor core 200. The process ofFIG. 8 proceeds fromblock 800 to block 802, which depicts ensuring that the cache line invalidations necessitated by transactional stores within the memory transaction have been fully propagated throughout the distributed shared memory system. In the embodiment described above, verification of propagation of the cache line invalidations necessitated by transactional stores is accomplished by one or more snoop machines 311 providing a retry response to any applicable TEND request onlocal interconnect 114 until the previous transactional stores have invalidated all cached copies of the memory location(s) targeted by the memory updates. The process then proceeds to step 804, which illustrates ensuring that the cache line invalidations necessitated by causally dependent non-transactional stores have completely propagated throughout the distributed shared memory system. In the embodiment described above, verification of propagation of the cache line invalidations necessitated by non-transactional stores is accomplished by one or more instances of causality resolution logic 379 providing a retry response to any applicable TEND request onlocal interconnect 114 until the previous memory updates of causally dependent non-transactional stores have invalidated all cached copies of the memory location(s) targeted by the memory updates. - At
block 806,transactional control logic 382 determines whether or not a conflict has occurred for the memory transaction. In response totransactional control logic 382 determining that a conflict has occurred, the process proceeds to block 808, which depictstransactional control logic 382 invalidating the tentative store footprint of the memory transaction (e.g., as recorded in L2 cache 230) and indicating via pass/fail indication 384 that the memory transaction has failed. As further illustrated atblock 808, in response to pass/fail indication 384processor core 200 updates its condition code register and transfers control to the fail handling branch instruction within the memory transaction (block 808). The process then terminates atstep 812. - Returning to block 806, in response to
transactional control logic 382 determining that no conflict has occurred during execution of the memory transaction, the process proceeds to step 810, which depictsTM control logic 382 committing the transaction, inter alia, by causing the transaction footprint to be committed to the distributed shared memory system (e.g., by updating one or more coherence states in thedirectory 308 ofL2 cache 230 to indicate the transaction footprint is valid and available for access by all threads) and indicating toprocessor core 200 via pass/fail indication 384 that the memory transaction passed. The process then terminates atblock 812. - With reference now to
FIG. 9 , there is depicted a block diagram of anexemplary design flow 900 used for example, in semiconductor IC logic design, simulation, test, layout, and manufacture.Design flow 900 includes processes, machines and/or mechanisms for processing design structures or devices to generate logically or otherwise functionally equivalent representations of the design structures and/or devices described above and shown inFIGS. 1-3 and 7. The design structures processed and/or generated bydesign flow 900 may be encoded on machine-readable transmission or storage media to include data and/or instructions that when executed or otherwise processed on a data processing system generate a logically, structurally, mechanically, or otherwise functionally equivalent representation of hardware components, circuits, devices, or systems. Machines include, but are not limited to, any machine used in an IC design process, such as designing, manufacturing, or simulating a circuit, component, device, or system. For example, machines may include: lithography machines, machines and/or equipment for generating masks (e.g. e-beam writers), computers or equipment for simulating design structures, any apparatus used in the manufacturing or test process, or any machines for programming functionally equivalent representations of the design structures into any medium (e.g. a machine for programming a programmable gate array). -
Design flow 900 may vary depending on the type of representation being designed. For example, adesign flow 900 for building an application specific IC (ASIC) may differ from adesign flow 900 for designing a standard component or from adesign flow 900 for instantiating the design into a programmable array, for example a programmable gate array (PGA) or a field programmable gate array (FPGA) offered by Altera® Inc. or Xilinx® Inc. -
FIG. 9 illustrates multiple such design structures including an input design structure 1020 that is preferably processed by adesign process 910.Design structure 920 may be a logical simulation design structure generated and processed bydesign process 910 to produce a logically equivalent functional representation of a hardware device.Design structure 920 may also or alternatively comprise data and/or program instructions that when processed bydesign process 910, generate a functional representation of the physical structure of a hardware device. Whether representing functional and/or structural design features,design structure 920 may be generated using electronic computer-aided design (ECAD) such as implemented by a core developer/designer. When encoded on a machine-readable data transmission, gate array, or storage medium,design structure 920 may be accessed and processed by one or more hardware and/or software modules withindesign process 910 to simulate or otherwise functionally represent an electronic component, circuit, electronic or logic module, apparatus, device, or system such as those shown inFIGS. 1-3 and 7. As such,design structure 920 may comprise files or other data structures including human and/or machine-readable source code, compiled structures, and computer-executable code structures that when processed by a design or simulation data processing system, functionally simulate or otherwise represent circuits or other levels of hardware logic design. Such data structures may include hardware-description language (HDL) design entities or other data structures conforming to and/or compatible with lower-level HDL design languages such as Verilog and VHDL, and/or higher level design languages such as C or C++. -
Design process 910 preferably employs and incorporates hardware and/or software modules for synthesizing, translating, or otherwise processing a design/simulation functional equivalent of the components, circuits, devices, or logic structures shown inFIGS. 1-3 and 7 to generate anetlist 980 which may contain design structures such asdesign structure 920.Netlist 980 may comprise, for example, compiled or otherwise processed data structures representing a list of wires, discrete components, logic gates, control circuits, I/O devices, models, etc. that describes the connections to other elements and circuits in an integrated circuit design.Netlist 980 may be synthesized using an iterative process in which netlist 980 is resynthesized one or more times depending on design specifications and parameters for the device. As with other design structure types described herein,netlist 980 may be recorded on a machine-readable storage medium or programmed into a programmable gate array. The medium may be a non-volatile storage medium such as a magnetic or optical disk drive, a programmable gate array, a compact flash, or other flash memory. Additionally, or in the alternative, the medium may be a system or cache memory, or buffer space. -
Design process 910 may include hardware and software modules for processing a variety of input data structuretypes including netlist 980. Such data structure types may reside, for example, withinlibrary elements 930 and include a set of commonly used elements, circuits, and devices, including models, layouts, and symbolic representations, for a given manufacturing technology (e.g., different technology nodes, 32 nm, 45 nm, 90 nm, etc.). The data structure types may further includedesign specifications 940,characterization data 950,verification data 960,design rules 970, and test data files 985 which may include input test patterns, output test results, and other testing information.Design process 910 may further include, for example, standard mechanical design processes such as stress analysis, thermal analysis, mechanical event simulation, process simulation for operations such as casting, molding, and die press forming, etc. One of ordinary skill in the art of mechanical design can appreciate the extent of possible mechanical design tools and applications used indesign process 910 without deviating from the scope and spirit of the invention.Design process 910 may also include modules for performing standard circuit design processes such as timing analysis, verification, design rule checking, place and route operations, etc. -
Design process 910 employs and incorporates logic and physical design tools such as HDL compilers and simulation model build tools to processdesign structure 920 together with some or all of the depicted supporting data structures along with any additional mechanical design or data (if applicable), to generate asecond design structure 990.Design structure 990 resides on a storage medium or programmable gate array in a data format used for the exchange of data of mechanical devices and structures (e.g., information stored in a IGES, DXF, Parasolid XT, JT, DRG, or any other suitable format for storing or rendering such mechanical design structures). Similar to designstructure 920,design structure 990 preferably comprises one or more files, data structures, or other computer-encoded data or instructions that reside on transmission or data storage media and that when processed by an ECAD system generate a logically or otherwise functionally equivalent form of one or more of the embodiments of the invention shown inFIGS. 1-3 and 7. In one embodiment,design structure 990 may comprise a compiled, executable HDL simulation model that functionally simulates the devices shown inFIGS. 1-3 and 7. -
Design structure 990 may also employ a data format used for the exchange of layout data of integrated circuits and/or symbolic data format (e.g., information stored in a GDSII (GDS2), GL1, OASIS, map files, or any other suitable format for storing such design data structures).Design structure 990 may comprise information such as, for example, symbolic data, map files, test data files, design content files, manufacturing data, layout parameters, wires, levels of metal, vias, shapes, data for routing through the manufacturing line, and any other data required by a manufacturer or other designer/developer to produce a device or structure as described above and shown inFIGS. 1-3 and 7.Design structure 990 may then proceed to astage 995 where, for example, design structure 990: proceeds to tape-out, is released to manufacturing, is released to a mask house, is sent to another design house, is sent back to the customer, etc. - As has been described, a data processing system implements a weak consistency memory model for a distributed shared memory system. The data processing system concurrently executes, on a plurality of processor cores, one or more transactional memory instructions within a memory transaction and one or more non-transactional memory instructions. The one or more non-transactional memory instructions include a non-transactional store instruction. The data processing system commits the memory transaction to the distributed shared memory system only in response to enforcement of causality of the non-transactional store instruction with respect to the memory transaction.
- While various embodiments have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the appended claims and these alternate implementations all fall within the scope of the appended claims.
Claims (7)
1. A method, comprising:
in a data processing system implementing a weak consistency memory model for a distributed shared memory system, concurrently executing on a plurality of processor cores one or more transactional memory instructions within a memory transaction and one or more non-transactional memory instructions, wherein the one or more non-transactional memory instructions include a non-transactional store instruction; and
committing the memory transaction to the distributed shared memory system of the data processing system only in response to enforcement of causality of the non-transactional store instruction with respect to the memory transaction.
2. The method of claim 1 , wherein:
the data processing system includes a system fabric that distributes memory access requests to the shared distributed memory system;
the memory transaction includes a transactional load instruction that reads a value stored to the distributed shared memory system by the non-transactional store instruction;
the method further includes snooping, on the system fabric, a store request corresponding to the non-transactional store instruction and snooping, on the system fabric, a read request corresponding to the transactional load instruction; and
the committing includes:
in response to snooping the read request while the store request is pending, preventing the memory transaction from committing until the store request is no longer pending.
3. The method of claim 2 , wherein preventing the memory transaction from committing includes providing a retry response to a request on the system fabric to commit the memory transaction.
4. The method of claim 1 , wherein the committing further includes committing the memory transaction only in response to an invalidation necessitated by a memory update of a transactional store instruction among the one or more transactional memory instructions in the memory transaction having fully propagated throughout the distributed shared memory system.
5. The method of claim 1 , and further comprising:
in response to detecting a conflict for the memory transaction, refraining from committing the transaction to the distributed shared memory system.
6. The method of claim 5 , and further comprising:
in response to detecting a conflict for the memory transaction, refraining from executing one or more instructions in the memory transaction and invoking execution of a fail handler.
7. The method of claim 1 , and further comprising controlling commitment of the memory transaction by one or more lower level store-in cache memories in the distributed shared memory system.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/777,161 US20140013055A1 (en) | 2012-07-06 | 2013-02-26 | Ensuring causality of transactional storage accesses interacting with non-transactional storage accesses |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/543,325 US9244846B2 (en) | 2012-07-06 | 2012-07-06 | Ensuring causality of transactional storage accesses interacting with non-transactional storage accesses |
US13/777,161 US20140013055A1 (en) | 2012-07-06 | 2013-02-26 | Ensuring causality of transactional storage accesses interacting with non-transactional storage accesses |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/543,325 Continuation US9244846B2 (en) | 2012-07-06 | 2012-07-06 | Ensuring causality of transactional storage accesses interacting with non-transactional storage accesses |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140013055A1 true US20140013055A1 (en) | 2014-01-09 |
Family
ID=49879416
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/543,325 Expired - Fee Related US9244846B2 (en) | 2012-07-06 | 2012-07-06 | Ensuring causality of transactional storage accesses interacting with non-transactional storage accesses |
US13/777,161 Abandoned US20140013055A1 (en) | 2012-07-06 | 2013-02-26 | Ensuring causality of transactional storage accesses interacting with non-transactional storage accesses |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/543,325 Expired - Fee Related US9244846B2 (en) | 2012-07-06 | 2012-07-06 | Ensuring causality of transactional storage accesses interacting with non-transactional storage accesses |
Country Status (1)
Country | Link |
---|---|
US (2) | US9244846B2 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140281236A1 (en) * | 2013-03-14 | 2014-09-18 | William C. Rash | Systems and methods for implementing transactional memory |
US9612963B2 (en) * | 2015-02-05 | 2017-04-04 | International Business Machines Corporation | Store forwarding cache |
WO2018111511A1 (en) * | 2016-12-12 | 2018-06-21 | Intel Corporation | Method and apparatus for memory consistency using cache coherency protocols |
US10108464B2 (en) | 2014-02-27 | 2018-10-23 | International Business Machines Corporation | Managing speculative memory access requests in the presence of transactional storage accesses |
CN109753721A (en) * | 2018-12-29 | 2019-05-14 | 广东高云半导体科技股份有限公司 | FPGA device placement-and-routing display methods, device, equipment and storage medium |
US11016820B2 (en) | 2013-08-26 | 2021-05-25 | Vmware, Inc. | Load balancing of resources |
US11210035B2 (en) | 2013-08-26 | 2021-12-28 | Vmware, Inc. | Creating, by host computers, respective object of virtual disk based on virtual disk blueprint |
US11249956B2 (en) | 2013-08-26 | 2022-02-15 | Vmware, Inc. | Scalable distributed storage architecture |
US12126536B2 (en) | 2020-10-29 | 2024-10-22 | VMware LLC | Distributed policy-based provisioning and enforcement for quality of service |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9696927B2 (en) * | 2014-06-19 | 2017-07-04 | International Business Machines Corporation | Memory transaction having implicit ordering effects |
US9361176B2 (en) * | 2014-06-25 | 2016-06-07 | International Business Machines Corporation | Detecting the use of stale data values due to weak consistency |
US10003648B2 (en) * | 2014-10-02 | 2018-06-19 | Samsung Electronics Co., Ltd. | Mechanism for universal parallel information access |
US9733940B2 (en) | 2014-11-17 | 2017-08-15 | International Business Machines Corporation | Techniques for instruction group formation for decode-time instruction optimization based on feedback |
US9940242B2 (en) | 2014-11-17 | 2018-04-10 | International Business Machines Corporation | Techniques for identifying instructions for decode-time instruction optimization grouping in view of cache boundaries |
US9952804B2 (en) | 2016-03-08 | 2018-04-24 | International Business Machines Corporation | Hardware transaction transient conflict resolution |
US10095637B2 (en) * | 2016-09-15 | 2018-10-09 | Advanced Micro Devices, Inc. | Speculative retirement of post-lock instructions |
US10379856B2 (en) * | 2017-06-04 | 2019-08-13 | International Business Machines Corporation | Multicopy atomic store operation in a data processing system |
US10318435B2 (en) * | 2017-08-22 | 2019-06-11 | International Business Machines Corporation | Ensuring forward progress for nested translations in a memory management unit |
CN112559434B (en) * | 2019-09-25 | 2023-12-08 | 阿里巴巴集团控股有限公司 | Multi-core processor and inter-core data forwarding method |
CN112749120B (en) * | 2019-10-29 | 2024-09-20 | 辉达公司 | Techniques for efficiently transferring data to a processor |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6272515B1 (en) * | 1996-07-11 | 2001-08-07 | Alstom | Method of scheduling distributed transactions |
US7421544B1 (en) * | 2005-04-04 | 2008-09-02 | Sun Microsystems, Inc. | Facilitating concurrent non-transactional execution in a transactional memory system |
US20100122073A1 (en) * | 2008-11-10 | 2010-05-13 | Ravi Narayanaswamy | Handling exceptions in software transactional memory systems |
US20100262786A1 (en) * | 2009-04-13 | 2010-10-14 | International Business Machines Corporation | Barriers Processing in a Multiprocessor System Having a Weakly Ordered Storage Architecture Without Broadcast of a Synchronizing Operation |
US20120079245A1 (en) * | 2010-09-25 | 2012-03-29 | Cheng Wang | Dynamic optimization for conditional commit |
US20130042077A1 (en) * | 2011-08-08 | 2013-02-14 | ARM, Limited | Data hazard handling for copending data access requests |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4420325B2 (en) | 2001-11-01 | 2010-02-24 | ベリサイン・インコーポレイテッド | Transaction memory management device |
US8321637B2 (en) | 2007-05-14 | 2012-11-27 | International Business Machines Corporation | Computing system with optimized support for transactional memory |
US8095741B2 (en) | 2007-05-14 | 2012-01-10 | International Business Machines Corporation | Transactional memory computing system with support for chained transactions |
US8095750B2 (en) | 2007-05-14 | 2012-01-10 | International Business Machines Corporation | Transactional memory system with fast processing of common conflicts |
US8402464B2 (en) | 2008-12-01 | 2013-03-19 | Oracle America, Inc. | System and method for managing contention in transactional memory using global execution data |
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 |
US9081501B2 (en) * | 2010-01-08 | 2015-07-14 | International Business Machines Corporation | Multi-petascale highly efficient parallel supercomputer |
US9626187B2 (en) | 2010-05-27 | 2017-04-18 | International Business Machines Corporation | Transactional memory system supporting unbroken suspended execution |
US8424015B2 (en) | 2010-09-30 | 2013-04-16 | International Business Machines Corporation | Transactional memory preemption mechanism |
US9298631B2 (en) * | 2012-06-15 | 2016-03-29 | International Business Machines Corporation | Managing transactional and non-transactional store observability |
-
2012
- 2012-07-06 US US13/543,325 patent/US9244846B2/en not_active Expired - Fee Related
-
2013
- 2013-02-26 US US13/777,161 patent/US20140013055A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6272515B1 (en) * | 1996-07-11 | 2001-08-07 | Alstom | Method of scheduling distributed transactions |
US7421544B1 (en) * | 2005-04-04 | 2008-09-02 | Sun Microsystems, Inc. | Facilitating concurrent non-transactional execution in a transactional memory system |
US20100122073A1 (en) * | 2008-11-10 | 2010-05-13 | Ravi Narayanaswamy | Handling exceptions in software transactional memory systems |
US20100262786A1 (en) * | 2009-04-13 | 2010-10-14 | International Business Machines Corporation | Barriers Processing in a Multiprocessor System Having a Weakly Ordered Storage Architecture Without Broadcast of a Synchronizing Operation |
US20120079245A1 (en) * | 2010-09-25 | 2012-03-29 | Cheng Wang | Dynamic optimization for conditional commit |
US20130042077A1 (en) * | 2011-08-08 | 2013-02-14 | ARM, Limited | Data hazard handling for copending data access requests |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2512470A (en) * | 2013-03-14 | 2014-10-01 | Intel Corp | Systems and methods for implementing transactional memory |
GB2512470B (en) * | 2013-03-14 | 2015-06-03 | Intel Corp | Systems and methods for implementing transactional memory |
US20140281236A1 (en) * | 2013-03-14 | 2014-09-18 | William C. Rash | Systems and methods for implementing transactional memory |
US11016820B2 (en) | 2013-08-26 | 2021-05-25 | Vmware, Inc. | Load balancing of resources |
US11809753B2 (en) | 2013-08-26 | 2023-11-07 | Vmware, Inc. | Virtual disk blueprints for a virtualized storage area network utilizing physical storage devices located in host computers |
US11704166B2 (en) | 2013-08-26 | 2023-07-18 | Vmware, Inc. | Load balancing of resources |
US11249956B2 (en) | 2013-08-26 | 2022-02-15 | Vmware, Inc. | Scalable distributed storage architecture |
US11210035B2 (en) | 2013-08-26 | 2021-12-28 | Vmware, Inc. | Creating, by host computers, respective object of virtual disk based on virtual disk blueprint |
US10108464B2 (en) | 2014-02-27 | 2018-10-23 | International Business Machines Corporation | Managing speculative memory access requests in the presence of transactional storage accesses |
US10169103B2 (en) | 2014-02-27 | 2019-01-01 | International Business Machines Corporation | Managing speculative memory access requests in the presence of transactional storage accesses |
US9697132B2 (en) | 2015-02-05 | 2017-07-04 | International Business Machines Corporation | Store forwarding cache |
US9612963B2 (en) * | 2015-02-05 | 2017-04-04 | International Business Machines Corporation | Store forwarding cache |
WO2018111511A1 (en) * | 2016-12-12 | 2018-06-21 | Intel Corporation | Method and apparatus for memory consistency using cache coherency protocols |
CN109753721A (en) * | 2018-12-29 | 2019-05-14 | 广东高云半导体科技股份有限公司 | FPGA device placement-and-routing display methods, device, equipment and storage medium |
US12126536B2 (en) | 2020-10-29 | 2024-10-22 | VMware LLC | Distributed policy-based provisioning and enforcement for quality of service |
Also Published As
Publication number | Publication date |
---|---|
US9244846B2 (en) | 2016-01-26 |
US20140013060A1 (en) | 2014-01-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9244846B2 (en) | Ensuring causality of transactional storage accesses interacting with non-transactional storage accesses | |
US9696928B2 (en) | Memory transaction having implicit ordering effects | |
US9244725B2 (en) | Management of transactional memory access requests by a cache memory | |
US9430166B2 (en) | Interaction of transactional storage accesses with other atomic semantics | |
US9430380B2 (en) | Managing memory transactions in a distributed shared memory system supporting caching above a point of coherency | |
US9396115B2 (en) | Rewind only transactions in a data processing system supporting transactional storage accesses | |
US9514049B2 (en) | Cache backing store for transactional memory | |
US9342454B2 (en) | Nested rewind only and non rewind only transactions in a data processing system supporting transactional storage accesses | |
US9367348B2 (en) | Protecting the footprint of memory transactions from victimization | |
US9798577B2 (en) | Transactional storage accesses supporting differing priority levels | |
US10108464B2 (en) | Managing speculative memory access requests in the presence of transactional storage accesses | |
US9390024B2 (en) | Bypassing a store-conditional request around a store queue | |
US10824567B2 (en) | Selectively preventing pre-coherence point reads in a cache hierarchy to reduce barrier overhead | |
US10831607B2 (en) | Dynamic transaction throttling in a data processing system supporting transactional memory |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FREY, BRADLY G.;MAY, CATHY;WILLIAMS, DEREK E;SIGNING DATES FROM 20120925 TO 20121016;REEL/FRAME:035410/0051 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |