Dynamic Store Atomicity Enforcement via Speculative Load Squashing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In out-of-order execution processor architectures, existing Total Store Order (TSO) implementations relax strict store atomicity, leading to violations where some threads see stores before others, potentially violating load→load order and memory consistency, especially due to store-to-load forwarding without ensuring global visibility of stores.
Innovation Solution
The system dynamically enforces store atomicity by marking processor core loads as speculative if they follow a load that receives data from a store buffer, preventing these loads from committing until the associated store is globally visible, and using identifier keys to manage load ordering and commit gates to ensure that only non-speculative loads can commit before stores are performed in shared memory.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If store-to-load forwarding is allowed in TSO implementation, then performance is improved and local thread sequential program semantics are safeguarded, but store atomicity is violated and load→load order may be violated
Solution Approach 1:
The patent implements dynamic store atomicity enforcement by introducing a speculative state that can be assigned and removed from loads based on runtime conditions. The system dynamically tracks whether a load follows a store-to-load forwarding and assigns speculative state accordingly, allowing the system to adapt between performance optimization and correctness enforcement based on the specific execution context.
Solution Approach 2:
The patent changes the state parameter of loads by introducing a speculative state flag. When a load receives data from a store buffer via store-to-load forwarding, subsequent loads are marked with this speculative state parameter. This parameter change enables the system to differentiate between speculative and non-speculative loads, controlling their commit behavior to maintain store atomicity when necessary.
2Reliability
If strict store atomicity is enforced for all loads, then store atomicity is preserved, but performance degradation occurs due to excessive speculation and squashing
Solution Approach 1:
The patent applies local quality by differentiating the treatment of individual loads based on their specific characteristics. Instead of uniformly enforcing store atomicity on all loads, the system selectively assigns speculative state only to loads that follow a store-to-load forwarding. This localized application of store atomicity enforcement ensures correctness where needed while avoiding unnecessary performance penalties for other loads.
Solution Approach 2:
The patent implements partial action by enforcing store atomicity only partially - specifically for loads that follow a store-to-load forwarding rather than for all loads. This selective enforcement approach applies the necessary constraint (speculative state assignment) only in the specific case where store atomicity could be violated, avoiding the excessive action of uniformly enforcing store atomicity on all loads which would cause performance degradation.
3Reliability
If younger loads are prevented from committing until store is globally visible, then store atomicity is maintained, but load→load ordering is violated and execution efficiency decreases
Solution Approach 1:
The patent implements dynamic control of load commitment by introducing the speculative state mechanism. Loads with speculative state are dynamically prevented from committing until the associated store is globally visible, while loads without speculative state can commit normally. This dynamic approach allows the system to maintain store atomicity only when necessary (for speculative loads) while preserving execution efficiency for non-speculative loads.
Data Source
AI summary
A computer system for dynamic enforcement of store atomicity includes multiple processor cores, local cache memory for each processor core, a shared memory, a separate store buffer for each processor core for executed stores that are not yet performed and a coherence mechanism. A first processor core load on a first processor core receives a value at a first time from a first processor core store in the store buffer and prevents any other first processor core load younger than the first processor core load in program order from committing until a second time when the first processor core store is performed. Between the first time and the second time any load younger in program load than the first processor core load and having an address matched by coherence invalidation or an address matched by an eviction is squashed.