US7228385B2 - Processor, data processing system and method for synchronizing access to data in shared memory - Google Patents

Processor, data processing system and method for synchronizing access to data in shared memory Download PDF

Info

Publication number
US7228385B2
US7228385B2 US10/965,113 US96511304A US7228385B2 US 7228385 B2 US7228385 B2 US 7228385B2 US 96511304 A US96511304 A US 96511304A US 7228385 B2 US7228385 B2 US 7228385B2
Authority
US
United States
Prior art keywords
store
load
cache
instruction
level cache
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.)
Expired - Fee Related, expires
Application number
US10/965,113
Other versions
US20060085603A1 (en
Inventor
Guy Lynn Guthrie
Sheldon B. Levenstein
William John Starke
Derek Edward Williams
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US10/965,113 priority Critical patent/US7228385B2/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LEVENSTEIN, SHELDON B., STARKE, WILLIAM JOHN, GUTHRIE, GUY LYNN, WILLIAMS, DEREK EDWARD
Publication of US20060085603A1 publication Critical patent/US20060085603A1/en
Application granted granted Critical
Publication of US7228385B2 publication Critical patent/US7228385B2/en
Assigned to GOOGLE INC. reassignment GOOGLE INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: INTERNATIONAL BUSINESS MACHINES CORPORATION
Assigned to GOOGLE LLC reassignment GOOGLE LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: GOOGLE INC.
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3824Operand accessing
    • G06F9/3834Maintaining memory consistency
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0811Multiuser, multiprocessor or multiprocessing cache systems with multilevel cache hierarchies
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0844Multiple simultaneous or quasi-simultaneous cache accessing
    • G06F12/0855Overlapped cache accessing, e.g. pipeline
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/3004Arrangements for executing specific machine instructions to perform operations on memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/30072Arrangements for executing specific machine instructions to perform conditional operations, e.g. using predicates or guards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/30076Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/30087Synchronisation or serialisation instructions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815Cache consistency protocols
    • G06F12/0831Cache consistency protocols using a bus scheme, e.g. with bus monitoring or watching means

Definitions

  • the present invention relates in general to data processing system and, in particular, to managing accesses to shared data in a data processing system. Still more particularly, the present invention relates to a processor, data processing system and method for synchronizing accesses to data in shared memory.
  • each of the multiple processors in the system may access and modify data stored in the shared memory.
  • load-reserve and store-conditional instruction pairs are often employed.
  • load-reserve and store-conditional instructions have been implemented in the PowerPC® instruction set architecture with operation codes (opcodes) associated with the LWARX and STWCX mnemonics, respectively (referred to hereafter as LARX and STCX).
  • load-reserve and store-conditional instruction pairs The goal of load-reserve and store-conditional instruction pairs is to load and modify data and then to commit the modified data to coherent memory only if no other thread of execution has modified the data in the interval between the load-reserve and store-conditional instructions.
  • updates to shared memory can be synchronized without the use of an atomic update primitive that strictly enforces atomicity.
  • FIG. 1 a block diagram of a conventional MP computer system supporting the use of load-reserve and store-conditional instructions to synchronize updates to shared memory is illustrated.
  • computer system 100 includes multiple processing units 102 a - 102 b for processing data and instructions.
  • Processing units 102 are coupled for communication to a system bus 104 for conveying address, data and control information between attached devices.
  • the attached devices include a memory controller 106 providing an interface to a system memory 108 and one or more host bridges 110 , each providing an interface to a respective mezzanine bus 112 .
  • Mezzanine bus 112 in turn provides slots for the attachment of additional devices, which may include network interface cards, I/O adapters, non-volatile storage device adapters, additional bus bridges, etc.
  • each processing unit 102 includes a processor core 120 containing an instruction sequencing unit 122 for fetching and ordering instructions for execution by one or more execution units 124 .
  • the instructions and associated data operands and data results are stored in a multi-level memory hierarchy having at its lowest level system memory 108 , and at its upper levels L1 cache 126 and L2 cache 130 .
  • the data within the memory hierarchy may generally be accessed and modified by multiple processing units 102 a , 102 b.
  • L1 cache 126 is a store-through cache, meaning that the point of cache coherency with respect to other processing units 102 is below the L1 cache (e.g., at L2 cache 130 ). L1 cache 126 therefore does not maintain true cache coherency states (e.g., Modified, Exclusive, Shared, Invalid) for its cache lines, but only maintains valid/invalid bits. Store operations first complete relative to the associated processor core 120 in the L1 cache and then complete relative to other processing units 102 in L2 cache 130 .
  • true cache coherency states e.g., Modified, Exclusive, Shared, Invalid
  • L2 cache 130 includes read-claim (RC) logic 142 for managing memory access requests by the associated processor core 120 , snoop logic 144 for managing memory access requests by other processing units 102 , and reservation logic 146 for recording reservations of the associated processor core 120 .
  • Reservation logic 146 includes at least one reservation register comprising a reservation address field 148 and a reservation flag 150 .
  • FIG. 2A depicts the manner in which a load-reserve (e.g., LARX) instruction is processed in data processing system 100 of FIG. 1 .
  • the process begins at block 200 , which represents the execution of a LARX instruction by execution units 124 of processing unit 102 a in order to determine the target address from which data is to be loaded.
  • L1 cache 126 invalidates the cache line containing the target address at block 202 .
  • the cache line is invalidated in L1 cache 126 to prevent the LARX instruction from binding to a potentially stale value in L1 cache 126 .
  • the value is potentially stale because another processing unit 102 may have gained ownership of the target cache line in order to modify it.
  • RC logic 142 stores the address of the reservation granule (e.g., cache line) containing the target address in reservation address field 148 and sets reservation flag 150 .
  • Reservation logic 146 then begins monitoring for an indication by snoop logic 144 that another processing unit 102 has updated the cache line containing the target address.
  • RC logic 142 obtains the load data from L2 cache array 140 , system memory 108 or another processing unit 102 and then returns the requested load data to processor core 120 .
  • processor core 120 stores the load data in an internal register, but not in L1 cache 126 .
  • Processor core 120 thereafter attempts to perform an atomic update to the load data through the execution of a store-conditional (e.g., STCX) instruction in accordance with the process depicted in FIG. 2B .
  • a store-conditional e.g., STCX
  • the process begins at block 220 , which represents execution units 124 executing the store-conditional instruction to determine the target address of the store-conditional operation.
  • the cache line containing the target address is invalidated in L1 cache 126 , if valid.
  • the cache line was invalidated earlier at block 202 , the invalidation is still performed at block 222 because an intervening load operation to another address in the cache line may have caused the cache line to be loaded back into L1 cache 126 .
  • processor core 120 issues a store-conditional (e.g., STCX) operation corresponding to the store-conditional instruction to RC logic 142 within L2 cache 130 , as shown at block 224 .
  • RC logic 142 obtains owner permission for the target cache line and then determines at block 226 whether or not reservation flag 150 is still set (i.e., whether or not any other processing unit 102 has modified the reservation granule). If reservation flag 150 is still set, indicating that no other processing unit 102 has modified the reservation granule, RC logic 142 updates L2 cache array 140 with the store data and resets reservation flag 150 , as shown at block 228 . Reservation logic 146 then sends a pass indication to processor core 120 , as shown at block 230 . Thereafter, the process ends at block 234 .
  • STCX store-conditional
  • reservation logic 146 transmits a fail indication to processor core 120 , as depicted at block 232 . Thereafter, processing of the store-conditional operation terminates at block 234 .
  • FIG. 2C illustrates the conventional operation of snoop logic 144 in support of shared memory updates utilizing load-reserve and store-conditional instructions.
  • the process begins at block 240 and thereafter proceeds to block 242 , which illustrates the process iterating until snoop logic 144 snoops an operation on system bus 104 .
  • snoop logic 144 allocates a snooper to handle the operation at block 244 .
  • the snooper determines at block 246 whether or not the snooped operation is a storage-modifying operation. If not, the process passes to block 252 for other processing and thereafter terminates at block 254 .
  • the snooper determines that the snooped operation is a storage-modifying operation, the snooper makes a further determination at block 248 whether the address of the modifying operation matches the contents of reservation address field 148 . If so, the snooper resets reservation flag 150 to cause any subsequent store-conditional operation to the address specified in reservation address field 148 to fail, as shown at block 250 . Following block 250 or following a determination at block 248 that the address of the snooped modifying operation matches the contents of reservation address field 148 , the snooper performs other processing at block 252 (e.g., updating the directory of L2 cache array 140 ). The process thereafter terminates at block 254 .
  • other processing e.g., updating the directory of L2 cache array 140
  • the present invention appreciates that the above-described conventional technique of updating shared memory utilizing load-reserve and store-conditional instructions has a number of drawbacks.
  • the conventional methodology described with respect to FIGS. 2A-2B is subject to significant communication latency in that it always requires two separate “round trip” communications between processor core 120 and L2 cache 130 .
  • the first “round trip” includes the issuance of a load-reserve operation to L2 cache 130 at block 204 and the return of the load data at block 208
  • the second “round trip” includes the issuance of a store-conditional operation to L2 cache 130 at block 224 and the return of a pass/fail indication at block 230 .
  • the conventional technique of updating shared memory utilizing load-reserve and store-conditional instructions disadvantageously results in the invalidation of the target cache line in L1 cache 126 .
  • one advantage of caching data is that software often exhibits locality of reference, meaning that data within the same cache line as the data updated by the load-reserve/store-conditional pair is frequently referenced by other nearby instructions.
  • the invalidation of the cache line in L1 cache 126 delays the execution of such instructions until the cache line is loaded back into L1 cache 126 from L2 cache 130 .
  • a processing unit for a multiprocessor data processing system includes a store-through upper level cache, an instruction sequencing unit that fetches instructions for execution, at least one instruction execution unit that executes a store-conditional instruction to determine a store target address, a store queue that, following execution of the store-conditional instruction, buffers a corresponding store operation, sequencer logic associated with the store queue.
  • the sequencer logic responsive to receipt of a latency indication indicating that resolution of the store-conditional operation as passing or failing is subject to significant latency, invalidates, prior to resolution of the store-conditional operation, a cache line in the store-through upper level cache to which a load-reserve operation previously bound.
  • FIG. 1 is a high level block diagram of a conventional data processing system that utilizes load-reserve and store conditional instructions to update shared memory;
  • FIG. 2A is a flowchart of a conventional method of processing a load-reserve instruction
  • FIG. 2B is a flowchart of a conventional method of processing a store-conditional instruction
  • FIG. 2C is a flowchart of a conventional method of processing operations snooped on a system bus
  • FIG. 3 is a high level block diagram of an illustrative data processing system in accordance with the present invention.
  • FIG. 4A is a high level logical flowchart of an exemplary method of processing a load-reserve instruction in accordance with the present invention
  • FIG. 4B is a high level logical flowchart of an exemplary method of processing a store-conditional instruction and corresponding store-conditional operation in a processor core in accordance with the present invention
  • FIG. 4C is a high level logical flowchart of an exemplary method of processing a store-conditional operation in lower level cache in accordance with the present invention.
  • FIG. 4D is a flowchart of an exemplary method of processing operations snooped on a system bus in accordance with the present invention.
  • data processing system 300 which may be, for example, a server or workstation computer, includes multiple processing units 302 a , 302 b for processing data and instructions.
  • Processing units 302 are coupled for communication to a system interconnect 304 for conveying address, data and control information between attached devices.
  • the attached devices include not only processing units 302 , but also a memory controller 306 providing an interface to a shared system memory 308 and one or more host bridges 310 , each providing an interface to a respective mezzanine bus 312 .
  • Mezzanine bus 312 in turn provides slots for the attachment of additional unillustrated devices, which may include network interface cards, I/O adapters, non-volatile memory, non-volatile storage device adapters, additional bus bridges, etc.
  • each processing unit 302 which may be realized as a single integrated circuit, includes one or more processor cores 320 a , 320 b for processing instructions and data.
  • Each processor core 320 includes execution units 324 for executing instructions and an instruction sequencing unit (ISU) 322 for fetching and ordering instructions for execution by the execution units 324 .
  • the instructions executed by execution units 324 include load-reserve and store-conditional instructions, which are utilized to synchronize access to shared memory between a particular thread of execution and other concurrent threads of execution, whether executing in the same processor core 320 , a different processor core 320 in the same processing unit 302 , or in a different processing unit 302 .
  • execution units 324 execute at least load-reserve and store-conditional instructions in-order (other instructions may or may not be executed out-of-order).
  • Each processor core 320 further includes an L1 store queue (STQ) 327 and a load unit 328 for managing the completion of store and load operations, respectively, corresponding to executed store and load instructions (including load-reserve and store-conditional instructions).
  • L1 STQ 327 is implemented as a First-In, First-Out (FIFO) queue containing a plurality of queue entries. Store operations are accordingly loaded in the “top” entry of L1 STQ 327 at execution of the corresponding store instruction to determine the target address, and are initiated when the store operation reaches the “bottom” or “commit” entry of L1 STQ 327 .
  • FIFO First-In, First-Out
  • Load and store “instructions” are defined herein as inputs to an execution unit that include an operation code (opcode) identifying the type of instruction and one or more operands specifying data to be accessed and/or its address.
  • Load and store “operations”, including load-reserve and store-conditional operations, are defined herein as data and/or signals generated following instruction execution that specify the address of data to be accessed.
  • load-reserve and store-conditional operations may be transmitted from a processor core 320 to lower level memory to initiate data accesses, while load-reserve and store-conditional instructions are not.
  • processor core 320 is supported by a multi-level volatile memory hierarchy having at its lowest level shared system memory 308 , and at its upper levels two or more levels of cache memory, which in the illustrative embodiment include L1 cache 326 and L2 cache 330 .
  • L2 cache 330 is shared by all processor cores 320 within a processing unit 302 .
  • the contents of the memory hierarchy may generally be accessed and modified by threads of execution executing in any processor core 320 in any processing unit 302 of data processing system 300 .
  • L1 cache 326 which may include bifurcated L1 data and instruction caches, is implemented as a store-through cache, meaning that the point of cache coherency with respect to other processor cores 320 is located below L1 cache 326 and, in the depicted embodiment, is located at L2 cache 330 . Accordingly, as described above, L1 cache 326 does not maintain true cache coherency states (e.g., Modified, Exclusive, Shared, Invalid) for its cache lines, but only maintains valid/invalid bits.
  • true cache coherency states e.g., Modified, Exclusive, Shared, Invalid
  • L1 cache 326 is implemented as a store-through cache, store operations (including store-conditional operations) first complete relative to the associated processor core 120 in L1 cache 326 and then complete relative to other processing units 302 at a point of system-wide coherency, which in the depicted embodiment is L2 cache 330 .
  • L2 cache 330 contains a storage array and directory 340 that store cache lines of instructions and data in association with their respective memory addresses.
  • L2 cache 330 also includes a number of instances of read-claim (RC) logic 342 a - 342 n for managing memory access operations received from the associated processor cores 320 .
  • RC logic instances 342 a - 342 n receive load operations from LD unit 328 in processor core 320 via load bus 360 and command bus 362 , and receive store operations from L1 STQ 327 in processor core 320 via store bus 364 , an in-order L2 STQ 366 , and command bus 362 .
  • L2 cache 330 further includes a number of instances of snoop (SN) logic 344 a - 344 n for managing memory access and other operations received from other processing units 302 via system interconnect 304 and snoop bus 370 .
  • Snoop logic instances 344 and RC logic instances 342 are each connected to a back-invalidation bus 372 by which any snoop logic instance 344 or RC logic instance 342 can signal the invalidation of a cache line to processor core 320 .
  • L2 cache 330 finally includes reservation logic 346 for recording reservations of the associated processor core(s) 320 .
  • reservation logic 346 includes, for each thread that may be concurrently executed by the processor core(s) 320 in its processing unit 302 , a respective reservation register comprising a reservation address field 348 and a reservation flag 350 .
  • reservation logic 346 includes two reservation registers: reservation address field 348 a and reservation flag 350 a for processor core 320 a and reservation address field 348 b and reservation flag 350 b for processor core 320 b .
  • reservation flag 350 When set (e.g., to ‘1’), a reservation flag 350 indicates that the associated processor core 320 holds a reservation for the address contained in reservation address field 348 and otherwise indicates no reservation is held.
  • Reservation logic 346 supplies pass/fail indications indicating the outcomes of store-conditional operations to processor cores 320 a , 320 b via respective pass/fail buses 374 a , 374 b.
  • FIG. 4A there is depicted a high level logical flowchart of an exemplary method by which data processing system 300 processes a load-reserve instruction in accordance with the present invention.
  • the process begins at block 400 and thereafter proceeds to block 402 , which illustrates execution units 324 receiving a load-reserve instruction, referred to hereinafter as a LARX instruction, from ISU 322 and then executing the LARX instruction to calculate the load target address.
  • execution units 324 execute LARX instructions within a hardware thread in-order and without pipelining, meaning that the data words(s) requested by a LARX instruction must be loaded to one or more registers 323 in processor core 320 before the next LARX instruction begins execution. These restrictions simplify the management of reservations by reservation logic 346 in L2 cache 330 .
  • the load target address is received from execution units 324 by LD unit 328 .
  • LD unit 328 accesses the directory of L1 cache 326 to determine whether a cache line containing the data word(s) associated with the load target address resides in L1 cache 326 . If not, L1 cache 326 signals a cache miss to LD unit 328 , which responds by issuing a LARX operation to an RC logic instance 342 via load bus 360 and command bus 362 , as shown at block 410 .
  • the RC logic instance 342 initiates an access to L2 storage array and directory 340 to retrieve the cache line of data identified by the load target address and returns the requested cache line to processor core 320 .
  • Processor core 320 loads the entire cache line of data within L1 cache 326 and transfers the data word(s) associated with the load target address in a core register 323 .
  • processor core 320 of data processing system 300 establishes the target cache line in L1 cache 326 to permit subsequent loads, and particularly subsequent load-reserve operations, to hit in L1 cache 326 .
  • the RC logic instance 342 establishes a reservation for the load target address in L2 cache 330 by placing the load target address in a reservation address field 348 and setting the associated reservation flag 350 . Thereafter, reservation logic 346 begins monitoring for an indication that the reservation granule has been updated, and the process terminates at block 416 .
  • LD unit 328 issues an address-only LARXA operation to an RC logic instance 342 via load bus 360 and command bus 362 to inform L2 cache 330 that the load-reserve has bound to a (potentially stale) value in L1 cache 326 .
  • processing unit 302 implements multiple processor cores 320 and/or processor core(s) 320 capable of executing multiple concurrent threads of execution, the LARXA operation preferably includes not only the load target address, but also the core ID and thread ID that executed the LARX instruction.
  • L1 cache 326 loads the data word(s) associated with the load target address into one or more core registers 323 associated with execution units 324 . Thereafter, the process passes to block 414 , which has been described.
  • the interval between processing of the LARXA operation by LD unit 328 at block 404 to the presentation of the LARXA operation on load bus 360 as depicted at block 406 must be a short, bounded time. It is not required, however, that this interval be fixed to a particular number of cycles.
  • execution units 324 ensure that no other load (including load-reserve) instructions are executed in any thread in the same processor core 320 within one L2 (not core) cycle of the execution of the load-reserve instruction.
  • load bus 360 will be available for LD unit 328 to transmit the LARXA operation to L2 cache 330 in a non-blocking fashion.
  • LD unit 328 ignores any busy signals on load bus 360 for purposes of presenting LARXA operations because LARXA operations are processed only by reservation logic 346 (and not RC logic instances 342 ) and therefore do not need to be delayed, even if RC logic instances 342 are all busy.
  • FIG. 4B there is a high level logical flowchart of an exemplary method of processing a store-conditional instruction in a processor core in accordance with the present invention.
  • the process begins at block 420 and thereafter proceeds to block 422 , which illustrates execution units 324 receiving a store-conditional instruction, referred to hereinafter as a STCX instruction, from ISU 322 and then executing the STCX instruction to calculate the store target address.
  • STCX instruction a store-conditional instruction
  • execution units 324 also preferably execute STCX instructions within the same hardware thread in-order and without pipelining.
  • execution units 324 Upon execution of the STCX instruction, execution units 324 place a corresponding STCX operation including the store target address within L1 STQ 327 , which is preferably implemented as a FIFO queue for buffering store operations that is shared by all threads executing within a processor unit 302 .
  • L1 STQ 327 issuing a STCX operation to L2 STQ 366 via store bus 364 when the STCX operation reaches the bottom (or “commit”) entry of L1 STQ 327 .
  • L1 STQ 327 determines, when the STCX operation reaches the commit entry of L1 STQ 327 , whether the STCX operation hit in L1 cache 326 .
  • the process passes to block 430 , which depicts L1 STQ 327 awaiting a pass/fail indication indicating whether or not the STCX operation succeeded at L2 cache 330 (i.e., with respect to all other threads and cache coherent processing units 302 ).
  • processor core 320 provides the pass/fail indication to execution units 324 (e.g., to indicate whether the path of execution should change), as shown at block 432 , but does not write to L1 cache 326 .
  • execution units 324 e.g., to indicate whether the path of execution should change
  • Block 440 illustrates L1 STQ 327 initiating sequencer logic 325 to manage the conditional update to L1 cache 326 . That is, because the success of the STCX operation is conditioned on the absence of other store operations to the same reservation granule following the point in time that the associated LARX operation binds to a value, the store data of the STCX operation cannot be placed in the L1 cache until the L2 has processed the STCX operation and ensured that it has completed successfully system-wide.
  • L1 STQ 327 is preferably implemented as a FIFO queue, meaning that until the STCX operation in the bottom or “commit” entry of L1 STQ 327 has finished and written to L1 cache 326 (if necessary), L1 STQ 327 is blocked and other store operations cannot make forward progress.
  • sequencer logic 325 of L1 STQ 327 preferably implements at least one mechanism by which sequencer logic 325 can discontinue waiting for the pass/fail indication from L2 cache 330 in order to update L1 cache 326 and can instead invalidate the target cache line in L1 cache 326 .
  • sequencer logic 325 of L1 STQ 327 implements two “escape” mechanisms to cause sequencer logic 325 to stop waiting for the pass/fail indication from L2 cache 330 in order to update L1 cache 326 .
  • the first of these mechanism is a respective cancel (or latency) signal from L2 cache 330 for each processor core 320 and thread that, when asserted, indicates that L2 cache 330 is likely to delay returning the pass/fail indication (e.g., because of an L2 cache miss, the target cache line is held in Shared state, etc.).
  • sequencer logic 325 of L1 STQ 327 when sequencer logic 325 of L1 STQ 327 receives the cancel (latency) signal, sequencer logic 325 of L1 STQ 327 invalidates the target cache line in L1 cache 326 if the target cache line is still valid.
  • sequencer logic 325 can abandon the update to L1 cache 326 .
  • T timeout counter
  • L1 STQ 327 starts timeout counter 329 in response to issuance of a STCX operation to L2 cache 330 , and in response to a predetermined, programmable number of cycles elapsing prior to receipt of a pass/fail indication from L2 cache 330 (as indicated by a latency signal generated by timeout counter 329 ), sequencer logic 325 similarly invalidates the target cache line in L1 cache 326 , as shown at block 442 and 444 .
  • L1 STQ 327 can continue to make forward progress on other store operations. The process thereafter proceeds from block 444 to block 430 , which has been described.
  • Block 450 illustrates L1 STQ 327 determining whether L1 cache 326 has deallocated the target cache line of the STCX operation or has invalidated the target cache line of the STCX operation, for example, in response to receipt of a back-invalidate signal on back-invalidation bus 372 . If so, the process passes to block 430 , which has been described. If not, L1 STQ 327 determines whether a pass/fail indication has been received from L2 cache 330 via pass/fail bus 374 .
  • sequencer logic 325 of L1 STQ 327 takes the appropriate action. Namely, if the pass/fail indication is a fail indication, the process passes to block 432 , which has been described. If, on the other hand, the pass/fail indication is a pass indication, sequencer logic 325 of L1 STQ 327 updates L1 cache 326 with the store data from the STCX operation, as depicted at block 456 . Thereafter, the process passes to block 432 , which has been described.
  • FIG. 4C there is depicted a high level logical flowchart of an exemplary method of processing a store-conditional operation in lower level cache in accordance with the present invention.
  • STCX operations are received by L2 cache 330 within L2 STQ 366 via store bus 364 .
  • L2 STQ 366 like L1 STQ 327 , is may be implemented as a FIFO queue.
  • Store operations, including STCX operations, pass from the bottom entry of L2 STQ 366 to RC logic instances 342 for processing.
  • an RC logic instance 342 determines by reference to the L2 directory within storage array and directory 340 whether or not L2 cache 330 holds the target cache line in an “owner” cache state, such as Modified or Exclusive, in which the target cache line can be updated without first obtaining modification (“owner”) rights from another processing unit 302 . If not, the RC logic instance 342 optionally issues a cancel signal to the processor core 320 , as shown at block 464 , to indicate that L1 STQ 327 should abandon the STCX update to L1 cache 326 .
  • owner modification
  • RC logic instance 342 obtains the target cache line in an “owner” state, for example, by issuing a read-with-intent-to-modify transaction on system interconnect 304 .
  • the process shown in FIG. 4C then proceeds to block 468 .
  • Block 468 illustrates the RC logic instance 342 determining whether or not a reservation flag 350 for the store target address is set (i.e., whether or not any other processing core 320 or thread has modified the reservation granule). If not, reservation logic 346 transmits a fail indication to processor core 320 via pass/fail bus 374 , as shown at block 470 . Thereafter, the process terminates at block 476 .
  • RC logic instance 342 updates the L2 cache array within storage array and directory 340 with the store data of the STCX operation and resets reservation flag 350 , as shown at block 472 .
  • Reservation logic 346 also sends a pass indication to processor core 320 at block 474 . Thereafter, the process ends at block 476 .
  • FIG. 4D there is illustrated a flowchart of an exemplary method of processing operations snooped on a system bus in accordance with the present invention.
  • the process begins at block 480 and thereafter proceeds to block 481 , which illustrates the process iterating until L2 cache 330 snoops an operation on system interconnect 304 .
  • L2 cache 330 allocates a snoop logic instance 344 to handle the operation at block 482 .
  • the snoop logic instance 344 determines at block 484 whether or not the snooped operation is a storage-modifying operation. If not, the process passes to block 486 for other processing (e.g., an L2 directory update) and thereafter terminates at block 498 .
  • other processing e.g., an L2 directory update
  • snoop logic instance 342 determines at block 484 that the snooped operation is a storage-modifying operation
  • snoop logic instance 344 makes a further determination whether the target address of the storage-modifying operation matches the contents of a reservation address field 348 . If not, the process passes to block 486 , which has been described. If, however, the target address of the snooped storage-modifying operation matches an address contained in a reservation address field 348 , snoop logic instance 344 resets the associated reservation flag 350 to cause any subsequent STCX operation to the address specified in reservation address field 348 to fail, as shown at block 490 .
  • the snoop logic instance 344 issues a back-invalidate signal specifying the target address of the snooped storage-modifying operation to processor core 320 (e.g., L1 cache 326 ) via back-invalidation bus 372 , as shown at block 492 .
  • the back-invalidate signal clears the associated cache line from L1 cache 326 , thus preventing subsequent LARX operations from hitting in the cache line. It should be noted that while the back-invalidation is underway, RC logic instances 342 and snoop logic instances 344 prevent any STCX or LARX (not LARXA) operations from proceeding until reservation flag 350 is reset and the cache line is invalidated in L1 cache 326 .
  • the snoop logic instance 344 waits a fixed interval of time, as illustrated at block 494 , to ensure that all (now stale) LARXA operations currently in flight to the given cache line have set a reservation flag 350 in reservation logic 346 .
  • This wait interval is accordingly equal to or greater than the bounded interval in which LD unit 328 issues LARXA operations to L2 cache 330 via load bus 360 .
  • the snoop logic instance 344 resets the reservation flag 350 , if any, associated with a reservation address field 348 containing an address matching the target address of the snooped storage-modifying operation.
  • the signal that resets the reservation flag 350 is a directory write operation that updates the L2 directory within storage array and directory 340 in response to the snooped operation.
  • reservation flags 350 set by stale LARXA operations are reset in order to satisfy the architectural requirement that a STCX operation conditioned upon a stale LARX must fail. The process thereafter terminates at block 498 .
  • the present invention provides improved processing units, data processing systems, and methods for synchronizing updates to shared memory utilizing load-reserve and store-conditional instructions.
  • load-reserve operations are permitted to bind to possibly stale values in the L1 cache prior to determining whether the values are stale. If it is determined that the value to which the load-reserve operation bound in the L1 cache is stale, a subsequent store-conditional operation to the same reservation granule fails. If the value is determined to not be stale, the subsequent store-conditional operation succeeds, and the cache line containing the value to which the load-reserve operation bound is advantageously retained in the L1 cache.

Abstract

A processing unit for a multiprocessor data processing system includes a store-through upper level cache, an instruction sequencing unit that fetches instructions for execution, at least one instruction execution unit that executes a store-conditional instruction to determine a store target address, a store queue that, following execution of the store-conditional instruction, buffers a corresponding store operation, sequencer logic associated with the store queue. The sequencer logic, responsive to receipt of a latency indication indicating that resolution of the store-conditional operation as passing or failing is subject to significant latency, invalidates, prior to resolution of the store-conditional operation, a cache line in the store-through upper level cache to which a load-reserve operation previously bound.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
The present application is related to the following applications, which are filed on even date herewith, assigned to the same assignee, and incorporated herein by reference in their entireties:
    • (1) U.S. patent application Ser. No. 10/965,151;
    • (2) U.S. patent application Ser. No. 10/965,144.
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates in general to data processing system and, in particular, to managing accesses to shared data in a data processing system. Still more particularly, the present invention relates to a processor, data processing system and method for synchronizing accesses to data in shared memory.
2. Description of the Related Art
In shared memory multiprocessor (MP) data processing systems, each of the multiple processors in the system may access and modify data stored in the shared memory. In order to synchronize access to a particular granule (e.g., cache line) of memory between multiple processing units and threads of execution, load-reserve and store-conditional instruction pairs are often employed. For example, load-reserve and store-conditional instructions have been implemented in the PowerPC® instruction set architecture with operation codes (opcodes) associated with the LWARX and STWCX mnemonics, respectively (referred to hereafter as LARX and STCX). The goal of load-reserve and store-conditional instruction pairs is to load and modify data and then to commit the modified data to coherent memory only if no other thread of execution has modified the data in the interval between the load-reserve and store-conditional instructions. Thus, updates to shared memory can be synchronized without the use of an atomic update primitive that strictly enforces atomicity.
With reference now to FIG. 1, a block diagram of a conventional MP computer system supporting the use of load-reserve and store-conditional instructions to synchronize updates to shared memory is illustrated. As shown, computer system 100 includes multiple processing units 102 a-102 b for processing data and instructions. Processing units 102 are coupled for communication to a system bus 104 for conveying address, data and control information between attached devices. In the depicted embodiment, the attached devices include a memory controller 106 providing an interface to a system memory 108 and one or more host bridges 110, each providing an interface to a respective mezzanine bus 112. Mezzanine bus 112 in turn provides slots for the attachment of additional devices, which may include network interface cards, I/O adapters, non-volatile storage device adapters, additional bus bridges, etc.
As further illustrated in FIG. 1, each processing unit 102 includes a processor core 120 containing an instruction sequencing unit 122 for fetching and ordering instructions for execution by one or more execution units 124. The instructions and associated data operands and data results are stored in a multi-level memory hierarchy having at its lowest level system memory 108, and at its upper levels L1 cache 126 and L2 cache 130. The data within the memory hierarchy may generally be accessed and modified by multiple processing units 102 a, 102 b.
L1 cache 126 is a store-through cache, meaning that the point of cache coherency with respect to other processing units 102 is below the L1 cache (e.g., at L2 cache 130). L1 cache 126 therefore does not maintain true cache coherency states (e.g., Modified, Exclusive, Shared, Invalid) for its cache lines, but only maintains valid/invalid bits. Store operations first complete relative to the associated processor core 120 in the L1 cache and then complete relative to other processing units 102 in L2 cache 130.
As depicted, in addition to the L2 cache array 140, L2 cache 130 includes read-claim (RC) logic 142 for managing memory access requests by the associated processor core 120, snoop logic 144 for managing memory access requests by other processing units 102, and reservation logic 146 for recording reservations of the associated processor core 120. Reservation logic 146 includes at least one reservation register comprising a reservation address field 148 and a reservation flag 150.
FIG. 2A depicts the manner in which a load-reserve (e.g., LARX) instruction is processed in data processing system 100 of FIG. 1. As shown, the process begins at block 200, which represents the execution of a LARX instruction by execution units 124 of processing unit 102 a in order to determine the target address from which data is to be loaded. Following execution of the LARX instruction, L1 cache 126 invalidates the cache line containing the target address at block 202. The cache line is invalidated in L1 cache 126 to prevent the LARX instruction from binding to a potentially stale value in L1 cache 126. The value is potentially stale because another processing unit 102 may have gained ownership of the target cache line in order to modify it.
Following block 202, the process passes to block 204, which illustrates processor core 120 issuing a LARX operation corresponding to the LARX instruction to RC logic 142 within L2 cache 130. As depicted at bock 206, RC logic 142 stores the address of the reservation granule (e.g., cache line) containing the target address in reservation address field 148 and sets reservation flag 150. Reservation logic 146 then begins monitoring for an indication by snoop logic 144 that another processing unit 102 has updated the cache line containing the target address. As illustrated at block 208, RC logic 142 obtains the load data from L2 cache array 140, system memory 108 or another processing unit 102 and then returns the requested load data to processor core 120. In response to receipt of the load data, processor core 120 stores the load data in an internal register, but not in L1 cache 126.
Processor core 120 thereafter attempts to perform an atomic update to the load data through the execution of a store-conditional (e.g., STCX) instruction in accordance with the process depicted in FIG. 2B. As shown, the process begins at block 220, which represents execution units 124 executing the store-conditional instruction to determine the target address of the store-conditional operation. Next, as depicted at block 222, the cache line containing the target address is invalidated in L1 cache 126, if valid. Although the cache line was invalidated earlier at block 202, the invalidation is still performed at block 222 because an intervening load operation to another address in the cache line may have caused the cache line to be loaded back into L1 cache 126.
Following block 222, processor core 120 issues a store-conditional (e.g., STCX) operation corresponding to the store-conditional instruction to RC logic 142 within L2 cache 130, as shown at block 224. RC logic 142 obtains owner permission for the target cache line and then determines at block 226 whether or not reservation flag 150 is still set (i.e., whether or not any other processing unit 102 has modified the reservation granule). If reservation flag 150 is still set, indicating that no other processing unit 102 has modified the reservation granule, RC logic 142 updates L2 cache array 140 with the store data and resets reservation flag 150, as shown at block 228. Reservation logic 146 then sends a pass indication to processor core 120, as shown at block 230. Thereafter, the process ends at block 234.
Returning to block 226, in response to a determination that reservation flag 150 is reset, indicating that another processing unit 102 has modified the reservation granule in the interval between execution of the load-reserve and store-conditional instructions, the store-conditional operation fails in L2 cache 130, and reservation logic 146 transmits a fail indication to processor core 120, as depicted at block 232. Thereafter, processing of the store-conditional operation terminates at block 234.
FIG. 2C illustrates the conventional operation of snoop logic 144 in support of shared memory updates utilizing load-reserve and store-conditional instructions. As depicted, the process begins at block 240 and thereafter proceeds to block 242, which illustrates the process iterating until snoop logic 144 snoops an operation on system bus 104. When snoop logic 144 snoops an operation on system bus 104, snoop logic 144 allocates a snooper to handle the operation at block 244. The snooper determines at block 246 whether or not the snooped operation is a storage-modifying operation. If not, the process passes to block 252 for other processing and thereafter terminates at block 254. If, however, the snooper determines that the snooped operation is a storage-modifying operation, the snooper makes a further determination at block 248 whether the address of the modifying operation matches the contents of reservation address field 148. If so, the snooper resets reservation flag 150 to cause any subsequent store-conditional operation to the address specified in reservation address field 148 to fail, as shown at block 250. Following block 250 or following a determination at block 248 that the address of the snooped modifying operation matches the contents of reservation address field 148, the snooper performs other processing at block 252 (e.g., updating the directory of L2 cache array 140). The process thereafter terminates at block 254.
SUMMARY OF THE INVENTION
The present invention appreciates that the above-described conventional technique of updating shared memory utilizing load-reserve and store-conditional instructions has a number of drawbacks. For example, the conventional methodology described with respect to FIGS. 2A-2B is subject to significant communication latency in that it always requires two separate “round trip” communications between processor core 120 and L2 cache 130. The first “round trip” includes the issuance of a load-reserve operation to L2 cache 130 at block 204 and the return of the load data at block 208, and the second “round trip” includes the issuance of a store-conditional operation to L2 cache 130 at block 224 and the return of a pass/fail indication at block 230.
In addition, the conventional technique of updating shared memory utilizing load-reserve and store-conditional instructions disadvantageously results in the invalidation of the target cache line in L1 cache 126. As will be appreciated, one advantage of caching data is that software often exhibits locality of reference, meaning that data within the same cache line as the data updated by the load-reserve/store-conditional pair is frequently referenced by other nearby instructions. Unfortunately, the invalidation of the cache line in L1 cache 126 delays the execution of such instructions until the cache line is loaded back into L1 cache 126 from L2 cache 130.
In view of these and additional shortcomings in the prior art, the present invention provides improved processors, data processing systems and methods for synchronizing updates to a shared memory utilizing load-reserve and store-conditional instructions. According to one embodiment, A processing unit for a multiprocessor data processing system includes a store-through upper level cache, an instruction sequencing unit that fetches instructions for execution, at least one instruction execution unit that executes a store-conditional instruction to determine a store target address, a store queue that, following execution of the store-conditional instruction, buffers a corresponding store operation, sequencer logic associated with the store queue. The sequencer logic, responsive to receipt of a latency indication indicating that resolution of the store-conditional operation as passing or failing is subject to significant latency, invalidates, prior to resolution of the store-conditional operation, a cache line in the store-through upper level cache to which a load-reserve operation previously bound.
All objects, features, and advantages of the present invention will become apparent in the following detailed written description.
BRIEF DESCRIPTION OF THE DRAWINGS
The novel features believed characteristic of the invention are set forth in the appended claims. However, the invention, as well as a preferred mode of use, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
FIG. 1 is a high level block diagram of a conventional data processing system that utilizes load-reserve and store conditional instructions to update shared memory;
FIG. 2A is a flowchart of a conventional method of processing a load-reserve instruction;
FIG. 2B is a flowchart of a conventional method of processing a store-conditional instruction;
FIG. 2C is a flowchart of a conventional method of processing operations snooped on a system bus;
FIG. 3 is a high level block diagram of an illustrative data processing system in accordance with the present invention;
FIG. 4A is a high level logical flowchart of an exemplary method of processing a load-reserve instruction in accordance with the present invention;
FIG. 4B is a high level logical flowchart of an exemplary method of processing a store-conditional instruction and corresponding store-conditional operation in a processor core in accordance with the present invention;
FIG. 4C is a high level logical flowchart of an exemplary method of processing a store-conditional operation in lower level cache in accordance with the present invention; and
FIG. 4D is a flowchart of an exemplary method of processing operations snooped on a system bus in accordance with the present invention.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENT
With reference again to the figures and in particular with reference to FIG. 3, there is illustrated a high level block diagram of an exemplary embodiment of a multiprocessor data processing system in accordance with the present invention. As shown, data processing system 300, which may be, for example, a server or workstation computer, includes multiple processing units 302 a, 302 b for processing data and instructions. Processing units 302 are coupled for communication to a system interconnect 304 for conveying address, data and control information between attached devices. The attached devices include not only processing units 302, but also a memory controller 306 providing an interface to a shared system memory 308 and one or more host bridges 310, each providing an interface to a respective mezzanine bus 312. Mezzanine bus 312 in turn provides slots for the attachment of additional unillustrated devices, which may include network interface cards, I/O adapters, non-volatile memory, non-volatile storage device adapters, additional bus bridges, etc.
As further illustrated in FIG. 3, each processing unit 302, which may be realized as a single integrated circuit, includes one or more processor cores 320 a, 320 b for processing instructions and data. Each processor core 320 includes execution units 324 for executing instructions and an instruction sequencing unit (ISU) 322 for fetching and ordering instructions for execution by the execution units 324. In accordance with the present invention, the instructions executed by execution units 324 include load-reserve and store-conditional instructions, which are utilized to synchronize access to shared memory between a particular thread of execution and other concurrent threads of execution, whether executing in the same processor core 320, a different processor core 320 in the same processing unit 302, or in a different processing unit 302. In a preferred embodiment, execution units 324 execute at least load-reserve and store-conditional instructions in-order (other instructions may or may not be executed out-of-order).
Each processor core 320 further includes an L1 store queue (STQ) 327 and a load unit 328 for managing the completion of store and load operations, respectively, corresponding to executed store and load instructions (including load-reserve and store-conditional instructions). In a preferred embodiment, L1 STQ 327 is implemented as a First-In, First-Out (FIFO) queue containing a plurality of queue entries. Store operations are accordingly loaded in the “top” entry of L1 STQ 327 at execution of the corresponding store instruction to determine the target address, and are initiated when the store operation reaches the “bottom” or “commit” entry of L1 STQ 327.
It is important to note that the present application makes a distinction between “instructions”, such as load-reserve and store-conditional instructions, and “operations”. Load and store “instructions” (including load-reserve and store-conditional instructions) are defined herein as inputs to an execution unit that include an operation code (opcode) identifying the type of instruction and one or more operands specifying data to be accessed and/or its address. Load and store “operations”, including load-reserve and store-conditional operations, are defined herein as data and/or signals generated following instruction execution that specify the address of data to be accessed. Thus, load-reserve and store-conditional operations may be transmitted from a processor core 320 to lower level memory to initiate data accesses, while load-reserve and store-conditional instructions are not.
The operation of processor core 320 is supported by a multi-level volatile memory hierarchy having at its lowest level shared system memory 308, and at its upper levels two or more levels of cache memory, which in the illustrative embodiment include L1 cache 326 and L2 cache 330. In the particular embodiment shown in FIG. 3, L2 cache 330 is shared by all processor cores 320 within a processing unit 302. As in other shared memory MP data processing systems, the contents of the memory hierarchy may generally be accessed and modified by threads of execution executing in any processor core 320 in any processing unit 302 of data processing system 300.
In accordance with the present invention, L1 cache 326, which may include bifurcated L1 data and instruction caches, is implemented as a store-through cache, meaning that the point of cache coherency with respect to other processor cores 320 is located below L1 cache 326 and, in the depicted embodiment, is located at L2 cache 330. Accordingly, as described above, L1 cache 326 does not maintain true cache coherency states (e.g., Modified, Exclusive, Shared, Invalid) for its cache lines, but only maintains valid/invalid bits. Because L1 cache 326 is implemented as a store-through cache, store operations (including store-conditional operations) first complete relative to the associated processor core 120 in L1 cache 326 and then complete relative to other processing units 302 at a point of system-wide coherency, which in the depicted embodiment is L2 cache 330.
As further illustrated in FIG. 1, L2 cache 330 contains a storage array and directory 340 that store cache lines of instructions and data in association with their respective memory addresses. L2 cache 330 also includes a number of instances of read-claim (RC) logic 342 a-342 n for managing memory access operations received from the associated processor cores 320. RC logic instances 342 a-342 n receive load operations from LD unit 328 in processor core 320 via load bus 360 and command bus 362, and receive store operations from L1 STQ 327 in processor core 320 via store bus 364, an in-order L2 STQ 366, and command bus 362.
L2 cache 330 further includes a number of instances of snoop (SN) logic 344 a-344 n for managing memory access and other operations received from other processing units 302 via system interconnect 304 and snoop bus 370. Snoop logic instances 344 and RC logic instances 342 are each connected to a back-invalidation bus 372 by which any snoop logic instance 344 or RC logic instance 342 can signal the invalidation of a cache line to processor core 320.
L2 cache 330 finally includes reservation logic 346 for recording reservations of the associated processor core(s) 320. Specifically, reservation logic 346 includes, for each thread that may be concurrently executed by the processor core(s) 320 in its processing unit 302, a respective reservation register comprising a reservation address field 348 and a reservation flag 350. For example, in the depicted example, which assumes that processor cores 320 a and 320 b can each execute a single thread, reservation logic 346 includes two reservation registers: reservation address field 348 a and reservation flag 350 a for processor core 320 a and reservation address field 348 b and reservation flag 350 b for processor core 320 b. When set (e.g., to ‘1’), a reservation flag 350 indicates that the associated processor core 320 holds a reservation for the address contained in reservation address field 348 and otherwise indicates no reservation is held. Reservation logic 346 supplies pass/fail indications indicating the outcomes of store-conditional operations to processor cores 320 a, 320 b via respective pass/fail buses 374 a, 374 b.
Referring now to FIG. 4A, there is depicted a high level logical flowchart of an exemplary method by which data processing system 300 processes a load-reserve instruction in accordance with the present invention. As shown, the process begins at block 400 and thereafter proceeds to block 402, which illustrates execution units 324 receiving a load-reserve instruction, referred to hereinafter as a LARX instruction, from ISU 322 and then executing the LARX instruction to calculate the load target address. In a preferred embodiment, execution units 324 execute LARX instructions within a hardware thread in-order and without pipelining, meaning that the data words(s) requested by a LARX instruction must be loaded to one or more registers 323 in processor core 320 before the next LARX instruction begins execution. These restrictions simplify the management of reservations by reservation logic 346 in L2 cache 330.
Following execution of the LARX instruction, the load target address is received from execution units 324 by LD unit 328. As illustrated at block 404, LD unit 328 then accesses the directory of L1 cache 326 to determine whether a cache line containing the data word(s) associated with the load target address resides in L1 cache 326. If not, L1 cache 326 signals a cache miss to LD unit 328, which responds by issuing a LARX operation to an RC logic instance 342 via load bus 360 and command bus 362, as shown at block 410.
Next, at block 412, the RC logic instance 342 initiates an access to L2 storage array and directory 340 to retrieve the cache line of data identified by the load target address and returns the requested cache line to processor core 320. Processor core 320 loads the entire cache line of data within L1 cache 326 and transfers the data word(s) associated with the load target address in a core register 323. Thus, unlike prior art processors that only load the data word(s) associated with the load target address in core register(s) and do not cache the target cache line, processor core 320 of data processing system 300 establishes the target cache line in L1 cache 326 to permit subsequent loads, and particularly subsequent load-reserve operations, to hit in L1 cache 326. Next, as illustrated at block 414, the RC logic instance 342 establishes a reservation for the load target address in L2 cache 330 by placing the load target address in a reservation address field 348 and setting the associated reservation flag 350. Thereafter, reservation logic 346 begins monitoring for an indication that the reservation granule has been updated, and the process terminates at block 416.
Returning to block 404, in response to LD unit 328 determining that the load target address hit in L1 cache 326, LD unit 328 issues an address-only LARXA operation to an RC logic instance 342 via load bus 360 and command bus 362 to inform L2 cache 330 that the load-reserve has bound to a (potentially stale) value in L1 cache 326. If processing unit 302 implements multiple processor cores 320 and/or processor core(s) 320 capable of executing multiple concurrent threads of execution, the LARXA operation preferably includes not only the load target address, but also the core ID and thread ID that executed the LARX instruction.
As shown at block 408, L1 cache 326 loads the data word(s) associated with the load target address into one or more core registers 323 associated with execution units 324. Thereafter, the process passes to block 414, which has been described.
In order to ensure that the reservation established at block 414 is properly subject to any snoop operations that may cancel the reservation, the interval between processing of the LARXA operation by LD unit 328 at block 404 to the presentation of the LARXA operation on load bus 360 as depicted at block 406 must be a short, bounded time. It is not required, however, that this interval be fixed to a particular number of cycles. To ensure the time to presentation of a LARXA operation is bounded, execution units 324 ensure that no other load (including load-reserve) instructions are executed in any thread in the same processor core 320 within one L2 (not core) cycle of the execution of the load-reserve instruction. This condition guarantees that load bus 360 will be available for LD unit 328 to transmit the LARXA operation to L2 cache 330 in a non-blocking fashion. In addition, LD unit 328 ignores any busy signals on load bus 360 for purposes of presenting LARXA operations because LARXA operations are processed only by reservation logic 346 (and not RC logic instances 342) and therefore do not need to be delayed, even if RC logic instances 342 are all busy.
With reference now to FIG. 4B, there is a high level logical flowchart of an exemplary method of processing a store-conditional instruction in a processor core in accordance with the present invention. As depicted, the process begins at block 420 and thereafter proceeds to block 422, which illustrates execution units 324 receiving a store-conditional instruction, referred to hereinafter as a STCX instruction, from ISU 322 and then executing the STCX instruction to calculate the store target address. As with LARX execution described above, execution units 324 also preferably execute STCX instructions within the same hardware thread in-order and without pipelining. Upon execution of the STCX instruction, execution units 324 place a corresponding STCX operation including the store target address within L1 STQ 327, which is preferably implemented as a FIFO queue for buffering store operations that is shared by all threads executing within a processor unit 302.
Following block 422, the process proceeds to block 424, which depicts L1 STQ 327 issuing a STCX operation to L2 STQ 366 via store bus 364 when the STCX operation reaches the bottom (or “commit”) entry of L1 STQ 327. In addition, as depicted at block 426, L1 STQ 327 determines, when the STCX operation reaches the commit entry of L1 STQ 327, whether the STCX operation hit in L1 cache 326. If the store target address misses in L1 cache 326 at the commit entry of L1 STQ 327, the process passes to block 430, which depicts L1 STQ 327 awaiting a pass/fail indication indicating whether or not the STCX operation succeeded at L2 cache 330 (i.e., with respect to all other threads and cache coherent processing units 302). In response to receipt of the pass/fail operation, processor core 320 provides the pass/fail indication to execution units 324 (e.g., to indicate whether the path of execution should change), as shown at block 432, but does not write to L1 cache 326. Thereafter, the STCX operation is deallocated from L1 STQ 327, and the process terminates at block 434.
Returning to block 426, in response to L1 STQ 327 determining that the store target address of the STCX operation hit in L1 cache 326 at the commit entry, the process proceeds to block 440. Block 440 illustrates L1 STQ 327 initiating sequencer logic 325 to manage the conditional update to L1 cache 326. That is, because the success of the STCX operation is conditioned on the absence of other store operations to the same reservation granule following the point in time that the associated LARX operation binds to a value, the store data of the STCX operation cannot be placed in the L1 cache until the L2 has processed the STCX operation and ensured that it has completed successfully system-wide.
As noted above, L1 STQ 327 is preferably implemented as a FIFO queue, meaning that until the STCX operation in the bottom or “commit” entry of L1 STQ 327 has finished and written to L1 cache 326 (if necessary), L1 STQ 327 is blocked and other store operations cannot make forward progress. In order to avoid a potential deadlock and/or performance degradation, sequencer logic 325 of L1 STQ 327 preferably implements at least one mechanism by which sequencer logic 325 can discontinue waiting for the pass/fail indication from L2 cache 330 in order to update L1 cache 326 and can instead invalidate the target cache line in L1 cache 326.
In a preferred embodiment, sequencer logic 325 of L1 STQ 327 implements two “escape” mechanisms to cause sequencer logic 325 to stop waiting for the pass/fail indication from L2 cache 330 in order to update L1 cache 326. The first of these mechanism is a respective cancel (or latency) signal from L2 cache 330 for each processor core 320 and thread that, when asserted, indicates that L2 cache 330 is likely to delay returning the pass/fail indication (e.g., because of an L2 cache miss, the target cache line is held in Shared state, etc.). As shown at blocks 442 and 444, when sequencer logic 325 of L1 STQ 327 receives the cancel (latency) signal, sequencer logic 325 of L1 STQ 327 invalidates the target cache line in L1 cache 326 if the target cache line is still valid.
The other mechanism by which sequencer logic 325 can abandon the update to L1 cache 326 is an optional timeout counter (T) 329. If implemented, L1 STQ 327 starts timeout counter 329 in response to issuance of a STCX operation to L2 cache 330, and in response to a predetermined, programmable number of cycles elapsing prior to receipt of a pass/fail indication from L2 cache 330 (as indicated by a latency signal generated by timeout counter 329), sequencer logic 325 similarly invalidates the target cache line in L1 cache 326, as shown at block 442 and 444. By abandoning the writeback of the store data to L1 cache 326 in this manner, L1 STQ 327 can continue to make forward progress on other store operations. The process thereafter proceeds from block 444 to block 430, which has been described.
Still referring to FIG. 4B, following a determination at block 442 that no cancel signal has been received from L2 cache 330 and no timeout has occurred, the process passes to block 450. Block 450 illustrates L1 STQ 327 determining whether L1 cache 326 has deallocated the target cache line of the STCX operation or has invalidated the target cache line of the STCX operation, for example, in response to receipt of a back-invalidate signal on back-invalidation bus 372. If so, the process passes to block 430, which has been described. If not, L1 STQ 327 determines whether a pass/fail indication has been received from L2 cache 330 via pass/fail bus 374. If not, the process returns to block 442, representing sequencer logic 325 of L1 STQ 327 waiting until a pass/fail signal or cancel signal is received or a timeout, invalidation or deallocation occurs. In response to a determination at block 452 that a pass/fail indication has been received, sequencer logic 325 of L1 STQ 327 takes the appropriate action. Namely, if the pass/fail indication is a fail indication, the process passes to block 432, which has been described. If, on the other hand, the pass/fail indication is a pass indication, sequencer logic 325 of L1 STQ 327 updates L1 cache 326 with the store data from the STCX operation, as depicted at block 456. Thereafter, the process passes to block 432, which has been described.
Referring now to FIG. 4C, there is depicted a high level logical flowchart of an exemplary method of processing a store-conditional operation in lower level cache in accordance with the present invention. As described above, STCX operations are received by L2 cache 330 within L2 STQ 366 via store bus 364. L2 STQ 366, like L1 STQ 327, is may be implemented as a FIFO queue. Store operations, including STCX operations, pass from the bottom entry of L2 STQ 366 to RC logic instances 342 for processing. As shown at block 462, when processing a STCX operation, an RC logic instance 342 determines by reference to the L2 directory within storage array and directory 340 whether or not L2 cache 330 holds the target cache line in an “owner” cache state, such as Modified or Exclusive, in which the target cache line can be updated without first obtaining modification (“owner”) rights from another processing unit 302. If not, the RC logic instance 342 optionally issues a cancel signal to the processor core 320, as shown at block 464, to indicate that L1 STQ 327 should abandon the STCX update to L1 cache 326. In addition, RC logic instance 342 obtains the target cache line in an “owner” state, for example, by issuing a read-with-intent-to-modify transaction on system interconnect 304. The process shown in FIG. 4C then proceeds to block 468.
Block 468 illustrates the RC logic instance 342 determining whether or not a reservation flag 350 for the store target address is set (i.e., whether or not any other processing core 320 or thread has modified the reservation granule). If not, reservation logic 346 transmits a fail indication to processor core 320 via pass/fail bus 374, as shown at block 470. Thereafter, the process terminates at block 476. If, on the other hand, a determination is made at block 468 that reservation flag 350 is still set, indicating that no other processor core 320 or thread has modified the reservation granule, RC logic instance 342 updates the L2 cache array within storage array and directory 340 with the store data of the STCX operation and resets reservation flag 350, as shown at block 472. Reservation logic 346 also sends a pass indication to processor core 320 at block 474. Thereafter, the process ends at block 476.
With reference now to FIG. 4D, there is illustrated a flowchart of an exemplary method of processing operations snooped on a system bus in accordance with the present invention. As depicted, the process begins at block 480 and thereafter proceeds to block 481, which illustrates the process iterating until L2 cache 330 snoops an operation on system interconnect 304. When L2 cache 330 snoops an operation on system interconnect 304, L2 cache 330 allocates a snoop logic instance 344 to handle the operation at block 482. The snoop logic instance 344 determines at block 484 whether or not the snooped operation is a storage-modifying operation. If not, the process passes to block 486 for other processing (e.g., an L2 directory update) and thereafter terminates at block 498.
If, however, the snoop logic instance 342 determines at block 484 that the snooped operation is a storage-modifying operation, snoop logic instance 344 makes a further determination whether the target address of the storage-modifying operation matches the contents of a reservation address field 348. If not, the process passes to block 486, which has been described. If, however, the target address of the snooped storage-modifying operation matches an address contained in a reservation address field 348, snoop logic instance 344 resets the associated reservation flag 350 to cause any subsequent STCX operation to the address specified in reservation address field 348 to fail, as shown at block 490. In addition, the snoop logic instance 344 issues a back-invalidate signal specifying the target address of the snooped storage-modifying operation to processor core 320 (e.g., L1 cache 326) via back-invalidation bus 372, as shown at block 492. The back-invalidate signal clears the associated cache line from L1 cache 326, thus preventing subsequent LARX operations from hitting in the cache line. It should be noted that while the back-invalidation is underway, RC logic instances 342 and snoop logic instances 344 prevent any STCX or LARX (not LARXA) operations from proceeding until reservation flag 350 is reset and the cache line is invalidated in L1 cache 326.
Following issuance of the back-invalidate signal, the snoop logic instance 344 waits a fixed interval of time, as illustrated at block 494, to ensure that all (now stale) LARXA operations currently in flight to the given cache line have set a reservation flag 350 in reservation logic 346. This wait interval is accordingly equal to or greater than the bounded interval in which LD unit 328 issues LARXA operations to L2 cache 330 via load bus 360. In response to the wait interval elapsing, the snoop logic instance 344 resets the reservation flag 350, if any, associated with a reservation address field 348 containing an address matching the target address of the snooped storage-modifying operation. In a preferred embodiment, the signal that resets the reservation flag 350, if necessary, is a directory write operation that updates the L2 directory within storage array and directory 340 in response to the snooped operation. Thus, reservation flags 350 set by stale LARXA operations are reset in order to satisfy the architectural requirement that a STCX operation conditioned upon a stale LARX must fail. The process thereafter terminates at block 498.
It should be noted that in embodiments of the present invention in which multiple processor cores 320 share an L2 cache 330, as shown in FIG. 3, reservations established by LARX and LARXA operations by processor core 320 a can be canceled (i.e. reset) not only by storage-modifying operations snooped by L2 cache 330 on system interconnect 304, but also by storage-modifying operations by another processor core 320 b sharing L2 cache 330. In such embodiments, the RC logic instance 342 receiving the storage-modifying operation from processor core 320 b performs the steps depicted in FIG. 4D in the same manner described above, as well as the storage update specified by the storage-modifying operation.
As has been described, the present invention provides improved processing units, data processing systems, and methods for synchronizing updates to shared memory utilizing load-reserve and store-conditional instructions. In accordance with the present invention, load-reserve operations are permitted to bind to possibly stale values in the L1 cache prior to determining whether the values are stale. If it is determined that the value to which the load-reserve operation bound in the L1 cache is stale, a subsequent store-conditional operation to the same reservation granule fails. If the value is determined to not be stale, the subsequent store-conditional operation succeeds, and the cache line containing the value to which the load-reserve operation bound is advantageously retained in the L1 cache.
While the invention has been particularly shown as described with reference to a preferred embodiment, 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 invention. For example, although the invention has been described with reference to a particular embodiment of a memory hierarchy in which L1 and L2 caches are incorporated within a processing unit, those skilled in the art will appreciate that additional levels of in-line or lookaside caches may be employed and that, in some embodiments of the invention, one or more levels of cache may be off chip.

Claims (16)

1. A processing unit for a multiprocessor data processing system, said processing unit comprising:
a store-through upper level cache;
an instruction sequencing unit that fetches instructions for execution;
at least one instruction execution unit that executes a store-conditional instruction to determine a store target address;
a store queue that, following execution of said store-conditional instruction, buffers a corresponding store operation; and
sequencer logic associated with the store queue that, responsive to receipt of a latency indication indicating that resolution of said store-conditional operation as passing or failing is subject to significant latency, invalidates, prior to resolution of said store-conditional operation, a cache line in said store-through upper level cache to which a load-reserve operation previously bound.
2. The processing unit of claim 1, wherein the multiprocessor data processing system includes a lower level cache supporting the processing unit, wherein said latency indication comprises an indication by said lower level cache.
3. The processing unit of claim 2, and further comprising the lower level cache.
4. The processing unit of claim 1, wherein said processing unit includes a timer, and wherein said latency indication is generated by said timer upon expiration of interval.
5. The processing unit of claim 1, wherein said sequencer logic, responsive to receipt of a pass indication without receiving a latency indication, said pass indication indicating that no conflicting store operation has been performed since the load-reserve operation, updates the store-through upper level cache in accordance with the store-conditional operation.
6. The processing unit of claim 1, wherein:
said at least one instruction execution unit executes the load-reserve instruction to determine a load target address; and
the processing unit, responsive to the execution of the load-reserve instruction, performs a corresponding load-reserve operation by accessing said store-through upper level cache utilizing said load target address to cause data associated with said load target address to be loaded from said store-through upper level cache into a data register and by establishing a reservation for a reservation granule including the load target address.
7. A data processing system, comprising:
a system memory;
a system interconnect; and
a plurality of processing units coupled to the system interconnect, at least a particular processing unit among said plurality of processing units including:
a store-through upper level cache;
an instruction sequencing unit that fetches instructions for execution;
at least one instruction execution unit that executes a store-conditional instruction to determine a store target address;
a store queue that, following execution of said store-conditional instruction, buffers a corresponding store operation; and
sequencer logic associated with the store queue that, responsive to receipt of a latency indication indicating that resolution of said store-conditional operation as passing or failing is subject to significant latency, invalidates, prior to resolution of said store-conditional operation, a cache line in said store-through upper level cache to which a load-reserve operation previously bound.
8. The data processing system of claim 7, wherein the data processing system includes a lower level cache supporting the particular processing unit, wherein said latency indication comprises an indication by said lower level cache.
9. The data processing system of claim 7, wherein said processing unit includes a timer, and wherein said latency indication is generated by said timer upon expiration of interval.
10. The data processing system of claim 7, wherein said sequencer logic, responsive to receipt of a pass indication without receiving a latency indication, said pass indication indicating that no conflicting store operation has been performed since the load-reserve operation, updates the store-through upper level cache in accordance with the store-conditional operation.
11. The data processing system of claim 7, wherein:
said at least one instruction execution unit executes the load-reserve instruction to determine a load target address; and
the particular processing unit, responsive to the execution of the load-reserve instruction, performs a corresponding load-reserve operation by accessing said store-through upper level cache utilizing said load target address to cause data associated with said load target address to be loaded from said store-through upper level cache into a data register and by establishing a reservation for a reservation granule including the load target address.
12. A method of processing in a multiprocessor data processing system including a memory hierarchy including a store-through upper level cache, a lower level cache and a system memory, said method comprising:
executing a store-conditional instruction to determine a store target address;
following execution of said store-conditional instruction, buffering a corresponding store operation; and
responsive to receipt of a latency indication indicating that resolution of said store-conditional operation as passing or failing is subject to significant latency, a processing core invalidating, prior to resolution of said store-conditional operation, a cache line in the store-through upper level cache to which a load-reserve operation previously bound.
13. The method of claim 12, and further comprising the processor core receiving said latency indication from said lower level cache.
14. The method of claim 12, wherein the processor core includes a timer, said method further comprising the processor core receiving said latency indication from the timer.
15. The method of claim 12, wherein the processor core, responsive to receipt of a pass indication without receiving a latency indication, said pass indication indicating that no conflicting store operation has been performed since the load-reserve operation, updates the store-through upper level cache in accordance with the store-conditional operation.
16. The method of claim 12, and further comprising:
executing the load-reserve instruction to determine a load target address; and
the processor core, responsive to the execution of the load-reserve instruction, performing a corresponding load-reserve operation by accessing said store-through upper level cache utilizing said load target address to cause data associated with said load target address to be loaded from said store-through upper level cache into a data register and by establishing a reservation for a reservation granule including the load target address.
US10/965,113 2004-10-14 2004-10-14 Processor, data processing system and method for synchronizing access to data in shared memory Expired - Fee Related US7228385B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/965,113 US7228385B2 (en) 2004-10-14 2004-10-14 Processor, data processing system and method for synchronizing access to data in shared memory

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/965,113 US7228385B2 (en) 2004-10-14 2004-10-14 Processor, data processing system and method for synchronizing access to data in shared memory

Publications (2)

Publication Number Publication Date
US20060085603A1 US20060085603A1 (en) 2006-04-20
US7228385B2 true US7228385B2 (en) 2007-06-05

Family

ID=36182157

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/965,113 Expired - Fee Related US7228385B2 (en) 2004-10-14 2004-10-14 Processor, data processing system and method for synchronizing access to data in shared memory

Country Status (1)

Country Link
US (1) US7228385B2 (en)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060085791A1 (en) * 2004-10-14 2006-04-20 International Business Machines Corporation Method for broadcasting a condition to threads executing on a plurality of on-chip processors
US20100100682A1 (en) * 2008-10-22 2010-04-22 International Business Machines Corporation Victim Cache Replacement
US20100100683A1 (en) * 2008-10-22 2010-04-22 International Business Machines Corporation Victim Cache Prefetching
US20100153647A1 (en) * 2008-12-16 2010-06-17 International Business Machines Corporation Cache-To-Cache Cast-In
US20100153650A1 (en) * 2008-12-16 2010-06-17 International Business Machines Corporation Victim Cache Line Selection
US20100235576A1 (en) * 2008-12-16 2010-09-16 International Business Machines Corporation Handling Castout Cache Lines In A Victim Cache
US20100235584A1 (en) * 2009-03-11 2010-09-16 International Business Machines Corporation Lateral Castout (LCO) Of Victim Cache Line In Data-Invalid State
US20100262778A1 (en) * 2009-04-09 2010-10-14 International Business Machines Corporation Empirically Based Dynamic Control of Transmission of Victim Cache Lateral Castouts
US20100262783A1 (en) * 2009-04-09 2010-10-14 International Business Machines Corporation Mode-Based Castout Destination Selection
US20100262784A1 (en) * 2009-04-09 2010-10-14 International Business Machines Corporation Empirically Based Dynamic Control of Acceptance of Victim Cache Lateral Castouts
US20100262782A1 (en) * 2009-04-08 2010-10-14 International Business Machines Corporation Lateral Castout Target Selection
US20110161587A1 (en) * 2009-12-30 2011-06-30 International Business Machines Corporation Proactive prefetch throttling
US20110161590A1 (en) * 2009-12-31 2011-06-30 International Business Machines Corporation Synchronizing access to data in shared memory via upper level cache queuing
US20110161588A1 (en) * 2009-12-30 2011-06-30 International Business Machines Corporation Formation of an exclusive ownership coherence state in a lower level cache
US20110161589A1 (en) * 2009-12-30 2011-06-30 International Business Machines Corporation Selective cache-to-cache lateral castouts
US8489819B2 (en) 2008-12-19 2013-07-16 International Business Machines Corporation Victim cache lateral castout targeting
US9390026B2 (en) 2014-02-27 2016-07-12 International Business Machines Corporation Synchronizing access to data in shared memory
US10884740B2 (en) 2018-11-08 2021-01-05 International Business Machines Corporation Synchronized access to data in shared memory by resolving conflicting accesses by co-located hardware threads
US11068407B2 (en) 2018-10-26 2021-07-20 International Business Machines Corporation Synchronized access to data in shared memory by protecting the load target address of a load-reserve instruction
US11086672B2 (en) 2019-05-07 2021-08-10 International Business Machines Corporation Low latency management of processor core wait state
US11106608B1 (en) 2020-06-22 2021-08-31 International Business Machines Corporation Synchronizing access to shared memory by extending protection for a target address of a store-conditional request
US11119781B2 (en) 2018-12-11 2021-09-14 International Business Machines Corporation Synchronized access to data in shared memory by protecting the load target address of a fronting load
US11693776B2 (en) 2021-06-18 2023-07-04 International Business Machines Corporation Variable protection window extension for a target address of a store-conditional request

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7254678B2 (en) * 2005-03-17 2007-08-07 International Business Machines Corporation Enhanced STCX design to improve subsequent load efficiency
US7480771B2 (en) * 2005-08-17 2009-01-20 Sun Microsystems, Inc. Conditional synchronization mechanisms allowing multiple store operations to become visible while a flagged memory location is owned and remains unchanged
US7680989B2 (en) 2005-08-17 2010-03-16 Sun Microsystems, Inc. Instruction set architecture employing conditional multistore synchronization
US8473683B2 (en) * 2010-01-08 2013-06-25 International Business Machines Corporation Ordering of guarded and unguarded stores for no-sync I/O
US10824567B2 (en) * 2018-12-04 2020-11-03 International Business Machines Corporation Selectively preventing pre-coherence point reads in a cache hierarchy to reduce barrier overhead
US11354243B1 (en) * 2020-11-17 2022-06-07 International Business Machines Corporation Accelerated processing of streams of load-reserve requests

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040073756A1 (en) * 2002-10-10 2004-04-15 International Business Machines Corporation Method, apparatus and system for managing released promotion bits
US20050132148A1 (en) * 2003-12-10 2005-06-16 International Business Machines Corp. Method and system for thread-based memory speculation in a memory subsystem of a data processing system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040073756A1 (en) * 2002-10-10 2004-04-15 International Business Machines Corporation Method, apparatus and system for managing released promotion bits
US20050132148A1 (en) * 2003-12-10 2005-06-16 International Business Machines Corp. Method and system for thread-based memory speculation in a memory subsystem of a data processing system

Cited By (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060085791A1 (en) * 2004-10-14 2006-04-20 International Business Machines Corporation Method for broadcasting a condition to threads executing on a plurality of on-chip processors
US8438569B2 (en) * 2004-10-14 2013-05-07 International Business Machines Corporation Broadcasting a condition to threads executing on a plurality of on-chip processors
US20100100682A1 (en) * 2008-10-22 2010-04-22 International Business Machines Corporation Victim Cache Replacement
US20100100683A1 (en) * 2008-10-22 2010-04-22 International Business Machines Corporation Victim Cache Prefetching
US8209489B2 (en) 2008-10-22 2012-06-26 International Business Machines Corporation Victim cache prefetching
US8347037B2 (en) 2008-10-22 2013-01-01 International Business Machines Corporation Victim cache replacement
US20100153647A1 (en) * 2008-12-16 2010-06-17 International Business Machines Corporation Cache-To-Cache Cast-In
US20100153650A1 (en) * 2008-12-16 2010-06-17 International Business Machines Corporation Victim Cache Line Selection
US20100235576A1 (en) * 2008-12-16 2010-09-16 International Business Machines Corporation Handling Castout Cache Lines In A Victim Cache
US8225045B2 (en) 2008-12-16 2012-07-17 International Business Machines Corporation Lateral cache-to-cache cast-in
US8499124B2 (en) 2008-12-16 2013-07-30 International Business Machines Corporation Handling castout cache lines in a victim cache
US8117397B2 (en) 2008-12-16 2012-02-14 International Business Machines Corporation Victim cache line selection
US8489819B2 (en) 2008-12-19 2013-07-16 International Business Machines Corporation Victim cache lateral castout targeting
US8949540B2 (en) 2009-03-11 2015-02-03 International Business Machines Corporation Lateral castout (LCO) of victim cache line in data-invalid state
US20100235584A1 (en) * 2009-03-11 2010-09-16 International Business Machines Corporation Lateral Castout (LCO) Of Victim Cache Line In Data-Invalid State
US8285939B2 (en) 2009-04-08 2012-10-09 International Business Machines Corporation Lateral castout target selection
US20100262782A1 (en) * 2009-04-08 2010-10-14 International Business Machines Corporation Lateral Castout Target Selection
US20100262783A1 (en) * 2009-04-09 2010-10-14 International Business Machines Corporation Mode-Based Castout Destination Selection
US20100262784A1 (en) * 2009-04-09 2010-10-14 International Business Machines Corporation Empirically Based Dynamic Control of Acceptance of Victim Cache Lateral Castouts
US8312220B2 (en) 2009-04-09 2012-11-13 International Business Machines Corporation Mode-based castout destination selection
US8327073B2 (en) 2009-04-09 2012-12-04 International Business Machines Corporation Empirically based dynamic control of acceptance of victim cache lateral castouts
US8347036B2 (en) 2009-04-09 2013-01-01 International Business Machines Corporation Empirically based dynamic control of transmission of victim cache lateral castouts
US20100262778A1 (en) * 2009-04-09 2010-10-14 International Business Machines Corporation Empirically Based Dynamic Control of Transmission of Victim Cache Lateral Castouts
US9110808B2 (en) 2009-12-30 2015-08-18 International Business Machines Corporation Formation of an exclusive ownership coherence state in a lower level cache upon replacement from an upper level cache of a cache line in a private shared owner state
US20110161587A1 (en) * 2009-12-30 2011-06-30 International Business Machines Corporation Proactive prefetch throttling
US20110161588A1 (en) * 2009-12-30 2011-06-30 International Business Machines Corporation Formation of an exclusive ownership coherence state in a lower level cache
US9189403B2 (en) 2009-12-30 2015-11-17 International Business Machines Corporation Selective cache-to-cache lateral castouts
US20110161589A1 (en) * 2009-12-30 2011-06-30 International Business Machines Corporation Selective cache-to-cache lateral castouts
US9619390B2 (en) 2009-12-30 2017-04-11 International Business Machines Corporation Proactive prefetch throttling
US8296519B2 (en) 2009-12-31 2012-10-23 International Business Machines Corporation Synchronizing access to data in shared memory via upper level cache queuing
US20110161590A1 (en) * 2009-12-31 2011-06-30 International Business Machines Corporation Synchronizing access to data in shared memory via upper level cache queuing
US9390026B2 (en) 2014-02-27 2016-07-12 International Business Machines Corporation Synchronizing access to data in shared memory
US9396127B2 (en) 2014-02-27 2016-07-19 International Business Machines Corporation Synchronizing access to data in shared memory
US11068407B2 (en) 2018-10-26 2021-07-20 International Business Machines Corporation Synchronized access to data in shared memory by protecting the load target address of a load-reserve instruction
US10884740B2 (en) 2018-11-08 2021-01-05 International Business Machines Corporation Synchronized access to data in shared memory by resolving conflicting accesses by co-located hardware threads
US11119781B2 (en) 2018-12-11 2021-09-14 International Business Machines Corporation Synchronized access to data in shared memory by protecting the load target address of a fronting load
US11086672B2 (en) 2019-05-07 2021-08-10 International Business Machines Corporation Low latency management of processor core wait state
US11106608B1 (en) 2020-06-22 2021-08-31 International Business Machines Corporation Synchronizing access to shared memory by extending protection for a target address of a store-conditional request
US11693776B2 (en) 2021-06-18 2023-07-04 International Business Machines Corporation Variable protection window extension for a target address of a store-conditional request

Also Published As

Publication number Publication date
US20060085603A1 (en) 2006-04-20

Similar Documents

Publication Publication Date Title
US7475191B2 (en) Processor, data processing system and method for synchronizing access to data in shared memory
US7228385B2 (en) Processor, data processing system and method for synchronizing access to data in shared memory
US8327074B2 (en) Synchronizing access to data in shared memory via upper level cache queuing
US7200717B2 (en) Processor, data processing system and method for synchronizing access to data in shared memory
US9390026B2 (en) Synchronizing access to data in shared memory
US7254678B2 (en) Enhanced STCX design to improve subsequent load efficiency
JP3431824B2 (en) Access method and processing device
US6269427B1 (en) Multiple load miss handling in a cache memory system
US7549025B2 (en) Efficient marking of shared cache lines
US20060026371A1 (en) Method and apparatus for implementing memory order models with order vectors
US20090106499A1 (en) Processor with prefetch function
WO2001050274A1 (en) Cache line flush micro-architectural implementation method and system
US20080086594A1 (en) Uncacheable load merging
US11086672B2 (en) Low latency management of processor core wait state
US6321303B1 (en) Dynamically modifying queued transactions in a cache memory system
WO2006085140A2 (en) Disable write back on atomic reserved line in a small cache system
US8856478B2 (en) Arithmetic processing unit, information processing device, and cache memory control method
US7197604B2 (en) Processor, data processing system and method for synchronzing access to data in shared memory
US11281582B2 (en) Completion logic performing early commitment of a store-conditional access based on a flag
US11061824B2 (en) Deferring cache state updates in a non-speculative cache memory in a processor-based system in response to a speculative data request until the speculative data request becomes non-speculative
US20100306475A1 (en) Data cache with modified bit array
US7130965B2 (en) Apparatus and method for store address for store address prefetch and line locking
US8108624B2 (en) Data cache with modified bit array
US6311254B1 (en) Multiple store miss handling in a cache memory memory system
US11693776B2 (en) Variable protection window extension for a target address of a store-conditional request

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GUTHRIE, GUY LYNN;LEVENSTEIN, SHELDON B.;STARKE, WILLIAM JOHN;AND OTHERS;REEL/FRAME:015300/0640;SIGNING DATES FROM 20041007 TO 20041012

STCF Information on status: patent grant

Free format text: PATENTED CASE

REMI Maintenance fee reminder mailed
FPAY Fee payment

Year of fee payment: 4

SULP Surcharge for late payment
AS Assignment

Owner name: GOOGLE INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:026664/0866

Effective date: 20110503

FPAY Fee payment

Year of fee payment: 8

AS Assignment

Owner name: GOOGLE LLC, CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:GOOGLE INC.;REEL/FRAME:044127/0735

Effective date: 20170929

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20190605