Glossary

Every term the book defines — 178 of them — with the chapter that introduced it. These are the same definitions behind the dotted-underline tooltips throughout the site.

178 shown

ackcount ch. 8: The sharer count the directory sends a GetM requestor so it knows how many Inv-Acks to await; MOSI adds a data-less AckCount message for upgrading owners.
acquire/release ch. 5: One-direction ordering operations: ACQUIRE orders itself before later loads/stores, RELEASE after earlier ones; ACQUIREs and RELEASEs stay SC-ordered among themselves.
adaptive routing ch. 8: Letting messages choose paths dynamically to avoid congestion; same-pair messages may then arrive out of order.
amo ch. 5: RISC-V single-instruction atomic memory operation whose load and store appear consecutively in the global memory order.
armor ch. 10: Lustig et al.'s framework for precisely specifying memory consistency models and algorithmically deriving correct fence mappings/translations between them.
atomic requests ch. 7: System property that a coherence request is ordered in the same cycle it is issued, eliminating any gap between issue and serialization.
atomic transactions ch. 7: System property that a subsequent request for a block may not appear until the current transaction's response completes.
axiomatic specification ch. 11: Specifying a system as mathematical axioms over observable actions and relations (program order, global memory order) — the formalism used for SC/TSO/XC in chapters 3–5, given its name.
backoff ch. 8: SGI Origin mechanism for running a directory protocol on two networks instead of three: when forwarding could deadlock, the directory sends the requestor a backoff message (on the response network) listing the nodes to contact, and the requestor re-sends to them on the request network.
buffered memory (sc spec2) ch. 11: Atomic memory front-ended by one global FIFO store queue; writes ack on enqueue and late-ack on drain; a load waits for its core's latest write to be late-acked. Still yields SC — an operational specification of consistency-directed coherence.
bypassing ch. 4: A load returning the value of its own core's latest program-order-earlier buffered store, overriding memory order.
cache coherence ch. 1: Making caches functionally invisible by propagating one processor's writes to other processors' caches; a means of supporting a consistency model, not a correctness definition itself.
cache controller ch. 6: The coherence controller at a private cache: a core side accepting loads/stores and returning values, and a network side issuing/receiving coherence messages; misses initiate coherence transactions.
cache inclusion ch. 9: A lower-level cache is inclusive if it holds a superset of the upper levels' blocks — enabling it to act as a SNOOP FILTER (miss ⇒ upper caches can't hold the block; AMD Bulldozer). Costs redundant storage and maintenance (recall/invalidate L1 copies on L2 eviction). Alternatives: exclusive (L2 block ⇒ not in L1) and non-inclusive (neither) hold more distinct blocks.
cache-centric naming ch. 6: Naming an LLC/memory block's state as the aggregation of its caches' states (the primer's convention); the alternative memory-centric naming uses the memory controller's own permissions.
causality ch. 5: "If I see a store and tell you about it, you will see it too"; implied by write atomicity but not vice versa.
coalescing write buffer ch. 5: Non-FIFO write buffer that merges non-consecutive stores to the same block; violates TSO but is legal under XC between FENCEs.
coarse directory ch. 8: A sharer-list bit represents K caches instead of one: less state, extra unnecessary Invalidations.
coarse-grained coherence tracking ch. 10: Tracking coherence state at region/page granularity so accesses to private or read-only regions skip the global directory; relieves the off-chip interconnect in multi-chip CPU-GPU systems.
coherence controller ch. 6: The finite state machine at each storage structure (logically one independent FSM per block); the controllers' message exchanges enforce the SWMR and data-value invariants.
coherence interface ch. 2: The boundary between pipeline and coherence protocol: read-request(location)→value and write-request(location, value)→ack.
coherence protocol ch. 1: The set of rules implemented by a system's distributed actors (cache and memory controllers) that prevents access to stale data.
coherence transaction ch. 6: A coherence request plus the other messages exchanged to satisfy it (e.g., the data response).
coherent dma ch. 9: DMA that participates in coherence so reads find the latest version (even M/O in a cache) and writes invalidate stale copies. Simplest form: give the DMA controller a coherent (single-block) cache. Streaming whole-block writes motivate special ops: GetM-NoData (permission without data) or PutNewData (update memory, invalidate everything). Alternative: OS page-flushing, shootdown-style (embedded only).
composability ch. 11: A property holds for an object iff it holds for its components. Linearizability is composable; SC is not — per-location SC does not imply system SC.
compound consistency model ch. 10: The semantics of a heterogeneous shared-memory machine: memory operations from each component device satisfy that device's ordering rules (not simply “the weaker model”).
conflicting accesses ch. 3: Two accesses from different threads to the same location where at least one is a store (or RMW).
consistency-agnostic coherence ch. 2: Coherence in which a write returns only after being made visible to all cores; presents the illusion of an atomic memory, independent of the consistency model.
consistency-directed coherence ch. 2: Coherence in which writes propagate asynchronously but the order writes become visible must obey the consistency model; the newer GPU-era category.
cooperative thread array (cta) ch. 10: Cluster of a kernel's threads guaranteed to map to the same SM and hence share its L1 (OpenCL: workgroup; CUDA: thread block).
correctness substrate ch. 9: Token coherence's safety-and-liveness layer: guarantees tokens are conserved and every request is eventually satisfied, independent of the performance protocol running above it.
cumulative fence ch. 5: A FENCE (Power) whose before/after sets recursively absorb other cores' accesses ordered before or after it.
data race ch. 5: Two conflicting data operations that appear in the global memory order without an intervening pair of transitively conflicting synchronization operations by the same threads.
data-race-free (drf) ch. 5: An execution in which no data operations race; a program is DRF if all its SC executions are DRF.
data-value invariant ch. 2: The value of a memory location at the start of an epoch equals its value at the end of its last read-write epoch.
deadlock ch. 9: Two or more actors each waiting for another to act — a cycle of resource dependences; nobody progresses. In coherence: protocol deadlocks (waiting for a message never sent), cache resource deadlocks (e.g., all TBEs held by own requests), and protocol-dependent network deadlocks (broken by the three virtual-network invariants).
dependency-induced ordering ch. 5: Ordering forced by syntactic address, data, or control dependencies in RVWMO (and Power) but not in XC.
directory cache ch. 8: An on-chip cache of directory entries; DRAM-backed in traditional designs, inclusive (no backing store) in modern ones.
directory entry ch. 8: Per-block directory record: stable state, owner identity, and sharer list (baseline: 2-bit state, log2N-bit owner, N-bit one-hot sharer vector).
directory protocol ch. 6: Cache controllers unicast requests to the block's home memory controller, whose directory tracks owner/sharer state and responds or forwards to the owner; scalable but adds indirection.
dirty ch. 6: A block value that is more recent than the LLC/memory copy, which this cache must eventually update; clean is the opposite.
epoch ch. 2: A slice of a memory location's lifetime during which one core has read-write access or some number of cores have read-only access.
eventual write-propagation ch. 3: Liveness property: a store eventually becomes visible to a load repeatedly attempting to read that location.
exclusive (e) ch. 6: Valid, exclusive, and clean; read-only; no other cache has a valid copy and the LLC/memory is up-to-date; treated as an ownership state in this primer (not all protocols agree).
fair arbitration ch. 9: An arbitration policy guaranteeing every requestor eventually wins — the standard cure for fixed-priority starvation on shared resources like snooping buses.
false sharing ch. 9: Cores read/write DIFFERENT data that happens to share a cache block, generating real coherence traffic for no real sharing. Likelihood grows with block size. Mitigations: sub-block coherence, or speculatively using stale data while permissions are fetched.
fence ch. 4: Instruction forcing all program-order-earlier memory operations into memory order before all later ones (a.k.a. memory barrier).
forward (f) ch. 6: A non-MOESI stable state like Owned except clean (the LLC/memory copy is up-to-date).
forwarded request (fwd-gets/fwd-getm) ch. 8: A request the directory redirects to the owner cache, which then responds directly to the original requestor — the middle hop of a three-hop transaction.
getm ch. 3: Coherence request to obtain a block in a read-write (Modified) state.
gets ch. 3: Coherence request to obtain a block in a read-only (Shared) state.
getv ch. 10: Read request in which the REQUESTOR takes responsibility for invalidating the block (via self-invalidation), so the directory need not track it — the key interface addition (vs. GetS) for stitching consistency-directed protocols (cf. Spandex).
global write completion time (gwct) ch. 10: The timestamp the L2 returns to a writer: the time by which the write is globally visible. Each SM tracks a per-thread max GWCT and stalls FENCEs until it.
hierarchical coherence protocol ch. 9: Separate intra-chip and inter-chip coherence protocols composed hierarchically: requests satisfiable on-chip never touch the outer protocol; each chip appears as one node (with coarse state) to the outer directory. Lets commodity chips use simple non-scalable designs. Examples: Sun Wildfire, AlphaServer GS320, Stanford DASH; Marty/Hill virtual hierarchies do it dynamically on flat multicores.
hll memory model ch. 5: A high-level language's memory contract (Java, C++), built on SC for DRF with atomic/synchronized tagging plus bounded semantics for racy programs.
home ch. 8: The directory (or directory/LLC bank) statically responsible for a block's memory and directory state — e.g., block B's home is directory B mod N.
home snoop ch. 8: QPI's scalable protocol mode: a directory protocol despite the name. Requests go to the home's directory, which forwards to exactly the nodes that need them; racing requests are ordered by arrival at the directory.
hwsync ch. 5: Power's heavyweight cumulative sync ordering everything before it ahead of everything after it; required for Store→Load ordering (Dekker) and IRIW.
icbi ch. 9: Power's 'instruction cache block invalidate' instruction — software-managed instruction-cache coherence: explicitly invalidates an i-cache entry after code is modified.
implicit acknowledgment ch. 7: With a total request order, a requestor can infer when every controller has seen its request, so snooping needs no acknowledgment messages (unlike directory protocols).
inclusive directory cache ch. 8: Holds entries for a superset of all blocks cached on chip, so a miss means Invalid everywhere: embedded in an inclusive LLC (extra bits per block) or a standalone duplicate-tag structure (CxK associativity).
inclusive llc ch. 6: An LLC holding a copy of every block cached anywhere in the system, letting memory omit explicit coherence state (absence from the LLC implies Invalid).
incoherence ch. 1: Accessing a stale copy of a datum after another actor has written the original.
instruction cache coherence ch. 9: Keeping instruction caches coherent with code-modifying stores (OS program loading, JIT compilation, runtime re-optimization). I-cache blocks are read-only (I or S); a GetM invalidates them. The hard part is in-pipeline instructions: AMD Opteron tracks in-flight instructions and flushes on change; Power leaves it to software via icbi.
inv / inv-ack ch. 8: The directory sends an Invalidation to each sharer on a GetM; each sharer acknowledges DIRECTLY TO THE REQUESTOR — explicit acks replace snooping's implicit ones.
invalid (i) ch. 6: No readable or writable copy: the block is absent or potentially stale; the primer does not distinguish absence ("Not Present") from staleness.
invalidate protocol ch. 2: The dominant protocol family maintaining SWMR: a read ends any other core's read-write epoch; a write also invalidates all other cached copies.
iriw ch. 5: Independent-Read-Independent-Write litmus test: two writers and two readers observing the writes in opposite orders; proper handling is necessary but not sufficient for write atomicity.
kernel (gpu) ch. 10: The unit of work a CPU offloads onto a GPU; typically comprises thousands of software threads.
last-level cache (llc) ch. 2: Shared, memory-side cache logically in front of memory; reduces latency and increases effective bandwidth, acts as the memory controller, and adds no extra coherence level.
lazy release consistency-directed coherence (lrcc) ch. 10: Only release stores obtain ownership (on behalf of prior stores); all coherence actions are deferred to the acquire, whose block state discriminates intra-CTA (owned locally: nothing to do) from inter-CTA (owned remotely: remote write-backs plus local self-invalidation).
lease ch. 10: The finite validity period a reader requests for a block; the L1 tags the block with it and the L2 keeps the maximum lease across all L1s.
limited pointer directory ch. 8: i pointers of log2C bits instead of a C-bit vector; overflow handled by Dir_iB (broadcast; Dir0B = stateless always-broadcast), Dir_iNB (evict a sharer), or Dir_iSW (software trap).
linearizability ch. 11: SC plus the requirement that a write take effect in real time between its invocation and response. Composable per location — which is why consistency-agnostic coherence (= per-location linearizability) can be enforced independently per block by distributed directories.
litmus test ch. 11: A small multithreaded program abstracting a synchronization idiom; the outcomes a memory model allows on it characterize the model (Dekker, message passing, the same-address “coherence” test).
livelock ch. 9: Actors keep acting and changing state but never progress — a special case of starvation. Classic coherence causes: NACK-retry storms, and the window of vulnerability (IS^D_I invalidation loops on contended blocks).
liveness ch. 9: The 'something good eventually happens' half of correctness: freedom from deadlock, livelock, and starvation.
load value axiom ch. 11: A load returns the value of the most recent same-address store before it in global memory order.
load-reserved/store-conditional (ldr/stc) ch. 5: Two-instruction RMW that is atomic iff no store to the same address appears between the LdR's source store and the StC in memory order.
logical bus ch. 7: Any interconnect providing totally ordered broadcast without a physical shared-wire bus: a tree serialized at its root (Starfire), or logical-time ordering on arbitrary topologies (Timestamp Snooping, INSO).
lwsync ch. 5: Power's lightweight cumulative sync ordering all combinations except Store→Load; suffices for the flag idiom and causality chains.
memory consistency model ch. 1: The precise, architecturally visible definition of shared-memory correctness in terms of loads and stores; usually admits multiple correct executions.
memory consistency speculation ch. 3: Executing memory operations out of order on the prediction that no other core can observe it, verified by cache-residency tracking or commit-time load replay.
memory controller (coherence) ch. 6: The coherence controller at the LLC/memory; usually network-side only, so it neither issues requests on behalf of loads/stores nor receives coherence responses.
memory order ch. 3: The total order (<m) on all cores' memory operations that an execution appears to perform.
mesif / home snoop / source snoop ch. 8: Intel QPI's five states — F is a clean read-only forwarder, exactly one holder, silently evictable (unlike dirty O) — and its two modes: directory-style Home Snoop vs. requestor-broadcast Source Snoop, which orders racing requests by whose snoop responses all reach the home first.
migratory m (mm) state ch. 9: A state equal to M for coherence purposes but marking 'obtained exclusively on a PREDICTED migratory read.' Store in MM → M (prediction confirmed). Other-GetS finding M → send exclusive data (predict migration continues); finding MM → pattern broken, send a shared copy and revert to S (or O), so pure readers still get S copies.
migratory sharing ch. 9: The pattern where a block is read-then-written by one core after another (classic critical-section data). Plain protocols pay a GetS AND a GetM per hop; migratory optimizations hand out exclusive data on the first read — via a predictor issuing GetM on load misses, or via the MM state.
model checking ch. 11: Exhaustive exploration of a state machine's state space against invariants such as SWMR: explicit-state (Murphi), symbolic, or bounded; parameterization generalizes exhaustive small-system results to arbitrary cores and addresses.
modified (m) ch. 6: Valid, exclusive, owned, and potentially dirty; the block may be read or written; the only valid copy; the LLC/memory copy is potentially stale.
moesi ch. 6: Sweazey and Smith's five classic stable states (Modified, Owned, Exclusive, Shared, Invalid); MSI is the fundamental core, with O and E as optimizations.
mshr ch. 6: Miss status handling register; tracks a pending transaction and holds the block's transient coherence state bits.
nack ch. 8: Negative acknowledgment forcing a requestor to re-issue its request; risks livelock (section 9.3.2), so this book's protocols avoid it (the SGI Origin's Upgrade race uses one).
non-binding prefetch ch. 3: A request that changes only a block's coherence state (via GetS/GetM), never registers or data; functionally a no-op for the consistency model.
null directory cache ch. 8: No directory state at all (Dir0B): every forwarded request is a broadcast, but the directory controller survives as the LLC controller and the protocol's ordering point.
observable actions ch. 11: The input/output actions at a system's interface (internal actions are invisible); their sequences define the system's behavior. Consistency model: loads/stores + values returned. Coherence protocol: read/write-request and read/write-return — a write's completion instant is observable for coherence but not for consistency.
offline (static) consistency testing ch. 11: Pre-deployment testing of a real or simulated machine: pseudo-random programs with global-order-reconstruction checkers (TSOtool — exact reconstruction is NP-complete; MTraceCheck), known-answer litmus suites on hardware (diy/litmus), genetic white-box test generation (McVersi).
online (dynamic) consistency testing ch. 11: Hardware support detecting consistency violations at runtime (catching transient and fabrication errors too): pruned hardware checkers, or Meixner–Sorin's reduction to two checkable invariants — the protocol enforces SWMR, and the pipeline interacts with it correctly.
operational specification ch. 11: Specifying a system as an abstract reference implementation (typically a state machine) whose exhibited behaviors define the legal ones; safety from internal state, liveness via temporal-logic side conditions. Chapter 3's switch and chapters 6–9's protocol tables are operational models.
out-of-thin-air ch. 5: A load result with no producing store, arising from speculative load-buffering cycles; forbidden by dependency-induced ordering.
owned (o) ch. 6: Valid, owned, and potentially dirty but NOT exclusive; read-only; other caches may hold read-only copies; the LLC/memory copy is potentially stale.
owner ch. 6: The coherence controller responsible for responding to requests for a block; in most protocols exactly one owner exists at all times, and owned blocks may not be evicted without transferring ownership.
peekaboo problem ch. 9: A consistency hazard of the window-of-vulnerability fix: a PREFETCHED block invalidated before its data arrives, then demand-referenced — performing the access on data arrival effectively orders it at invalidation time, reordering it against program-order-earlier accesses and violating SC/TSO. Fix: perform the access iff it was the oldest load/store in program order when the request was issued.
per-location sc ch. 11: Every memory location individually sequentially consistent. Too weak to fully specify either coherence class, but a standard safety check — weak memory models' “coherence axiom.”
performance protocol ch. 9: Token coherence's policy layer: what a cache controller does on a miss (TokenB: broadcast; TokenM: multicast to predicted sharers). Free to be aggressive — the correctness substrate catches everything.
performed w.r.t. ch. 5: A store is performed with respect to core Ci once Ci's loads can no longer return the pre-store value; Power orders stores per-core rather than via one total memory order.
pipeline ordering axioms ch. 11: Microarchitectural happens-before axioms over per-stage sub-actions (fetch, decode, …, exits-store-buffer, memory-write) that faithfully model a pipeline (PipeCheck). An acyclic set of required edges = permitted behavior; a cycle = forbidden.
pipelined bus ch. 7: A non-atomic bus whose responses arrive in the same order as their requests.
point-to-point ordering ch. 8: Messages between the same source and destination arrive in send order; assumed on the forwarded-request network, and incompatible with unrestricted adaptive routing.
preserved program order (ppo) axiom ch. 11: The global memory order respects each core's program order — SC's first safety axiom, shrunk by relaxed models.
processor consistency (pc) ch. 4: A core's stores reach other cores in order but not necessarily at the same time; TSO is the special case with immediate self-visibility and all-at-once other-visibility.
program order ch. 3: The per-core total order (<p) of a core's memory operations as specified by its program.
protogen ch. 11: Correct-by-construction protocol design: automatically generates the complete concurrent protocol (transient states and actions included) from an atomic specification with only stable states — the shape of chapter 10's tables.
put transactions (puts/pute/puto/putm) ch. 6: Eviction transactions for blocks in Shared/Exclusive/Owned/Modified state; PutM and PutO carry data; PutS and PutE may be silent in some protocols.
put-ack ch. 8: The directory's acknowledgment that completes a Put transaction; until it arrives the evicting cache remains effectively in its old state.
rcc-o ch. 10: RCC plus ownership: every store obtains ownership (O at the L1, owner identity at the L2). Owned blocks skip release write-backs and acquire self-invalidations, and an acquire hitting an owned block proves intra-CTA synchronization without scope information.
read-modify-write (rmw) ch. 3: An atomic instruction (e.g., test-and-set, fetch-and-increment, compare-and-swap) whose load and store appear consecutively in memory order.
recall ch. 8: A directory-initiated eviction of a block from all caches, used when a limited-associativity directory-cache set fills; kept rare by sizing (at least 2x aggregate cache capacity) and non-silent PutS.
refinement (simulation) ch. 11: Proving implementation Q's behaviors are contained in specification S's via an abstraction function F from Q-states to S-states that preserves initial states and observable transitions. Making F work surfaces the protocol's invariants (e.g., SWMR).
relaxed memory model ch. 5: A (weak) consistency model preserving only the orders programmers require, giving hardware and software more optimization latitude.
release consistency (rc) ch. 5: Relaxed model observing that an acquire needs only a succeeding fence and a release only a preceding one, replacing full FENCEs with one-direction ACQUIRE/RELEASE.
release consistency-directed coherence (rcc) ch. 10: Protocol enforcing release consistency directly: a release writes back all dirty L1 blocks; an acquire reads a fresh copy from the L2 and self-invalidates all other valid blocks. CTA-scoped synchronization skips both.
reorder unit ch. 5: Queue between a core and the memory system that may reorder loads and stores subject to the FENCE, same-address, and bypassing rules.
replacement hint ch. 8: A PutS piggybacked on a GetS/GetM naming the replaced way (same set index); required for duplicate-tag directory caches despite the name 'hint'.
rvwmo ch. 5: RISC-V Weak Memory Order: XC-style total memory order plus RC-style ACQUIRE/RELEASE annotations, FENCE variants, and dependency-induced orderings.
safety ch. 9: The 'nothing bad ever happens' half of correctness — coherence's SWMR and data-value invariants. Trivially satisfiable by doing nothing; must be paired with liveness.
sc for drf ch. 5: The contract that all executions of data-race-free programs are SC executions; programmers label synchronization, implementations map it to FENCEs/RMWs.
sc for hrf ch. 10: Sequential Consistency for Heterogeneous-Race-Free: HSA/OpenCL language models extending SC-for-DRF with scopes. HRF-direct lets only identically scoped operations synchronize; HRF-indirect adds transitive synchronization across scopes.
scope ch. 10: The set of threads a synchronization operation applies to (CTA / GPU / System), implicitly naming the memory-hierarchy level those threads share (L1 / L2 / LLC).
scoped consistency model ch. 10: Consistency model whose atomic operations carry scopes; a release synchronizes with an acquire only if the acquire reads the release's value AND each operation's scope includes the thread executing the other. Formalized with Shasha–Snir-style partial orders (NVIDIA PTX).
scratchpad ch. 10: Programmer-managed on-SM memory outside the cache hierarchy; integrating scratchpads into the global shared address space remains ongoing research.
selective gpu caching ch. 10: Low-complexity CPU-GPU coherence: the GPU never caches data mapped to CPU memory nor GPU-memory data currently cached by the CPU (enforced via a coarse-grained remote directory). Trivially coherent; request coalescing and CPU-side caching offset the penalty.
self-invalidation ch. 10: The reading core invalidates blocks in its own cache to make other threads' stores visible, replacing writer-initiated invalidation — the enabling idea of GPU coherence.
sequential consistency (sc) ch. 3: The result of any execution equals some total order (memory order) of all cores' loads and stores in which each core's operations appear in its program order (Lamport).
serialization point ch. 7: The mechanism where the network fixes the order of coherence requests (bus arbitration logic, tree root); a requestor learns its own request's place by snooping the request stream.
shared (s) ch. 6: Valid but not exclusive, not dirty, and not owned; a read-only copy that other caches may also hold.
shared memory system ch. 1: A system in which processor cores read and write a single shared address space.
shim ch. 10: Per-device translator between a local coherence protocol and the global coherence controller's interface (e.g., a snooping device's shim interprets a global Inv as a GetM).
silent eviction ch. 6: Evicting a block without sending any message; permitted for non-owned states (S, sometimes E) in some protocols.
simt ch. 10: Single-Instruction-Multiple-Threads: warp-wide instruction issue with per-thread mask bits selecting which threads execute.
snoop response (aggregated) ch. 7: Power5 ring mechanism: each node appends its aggregated intended action as the request circles the ring; the requestor then broadcasts a decision message naming the responder.
snooping protocol ch. 6: Cache controllers broadcast requests to all coherence controllers, which collectively "do the right thing" (the owner responds); relies on ordered — typically totally ordered — request delivery.
source snoop ch. 8: QPI's low-latency protocol mode for small systems: the REQUESTOR broadcasts to all nodes; each node sends the home a snoop response; a request is ordered only when all of its snoop responses have reached the home. Lower common-case latency than home snoop, more bandwidth, more complex races.
split-transaction bus ch. 7: A non-atomic bus whose responses may arrive out of request order; responses must carry the identity of the request or requestor.
stable state ch. 6: A block state outside any in-flight transaction; the states a protocol is named by (e.g., "a MESI protocol").
starvation ch. 9: Some cores never progress while others do. Root causes: unfair arbitration (fixed-priority buses) — fixed by fair arbitration — and misused NACKs whose retries are never guaranteed to succeed.
streaming multiprocessor (sm) ch. 10: A GPU core: highly multithreaded (on the order of a thousand threads), whose threads share its L1 cache and scratchpad. AMD calls it a Compute Unit.
strictly more relaxed ch. 4: Model Y is strictly more relaxed (weaker) than X iff every X execution is a Y execution but not vice versa; models can also be incomparable.
sub-block coherence ch. 9: Maintaining coherence state at sub-block granularity so different sub-blocks of one cache block can be in different states — reduces false sharing at the cost of extra state bits.
swmr invariant ch. 2: Single-writer–multiple-reader: for any memory location at any moment, either one core may write (and read) it, or some number of cores may only read it.
synchronization operation ch. 5: A memory operation tagged as synchronization (e.g., lock acquire or release); untagged operations are data operations by default.
synonyms ch. 9: Multiple virtual addresses mapping to the same physical address — in a virtual cache they can be resident simultaneously, so one physical block lives at several cache locations, complicating coherence and reverse translation.
tagged (t) state ch. 7: Power5 state for an M block that received a GetS: a store may transition to M immediately, issuing a prioritized non-silent invalidation; SWMR holds in ring-logical (not physical) time; optimizes producer-consumer sharing.
temporal coherence ch. 10: Lease-based self-invalidation protocol on globally synchronized timestamps: readers hold blocks for a lease and self-invalidate at expiry. The consistency-agnostic variant stalls writes at the L2 until expiry (SWMR ⇒ SC); the consistency-directed variant returns GWCTs and stalls FENCEs instead (XC-like).
the 4ps ch. 4: Programmability, Performance, Portability, Precision: criteria for a good memory consistency model.
three-hop transaction ch. 8: Request to the home, forward to the owner, response to the requestor — the indirection latency directory protocols pay for scalability.
tlb shootdown ch. 9: The traditional software-managed TLB coherence scheme: the initiator invalidates the page-table entry, interrupts all cores; each traps, invalidates/flushes its TLB entries, flushes the pipeline, and acks back; the initiator waits for all acks before modifying the translation. Power's tlbie instruction replaces the inter-processor interrupts with a hardware broadcast.
token coherence ch. 9: Martin et al.'s third protocol class (2003): T tokens per block, exchanged but never created/destroyed; holding ≥1 token permits reads, all T permits writes. Split into a correctness substrate (token conservation = safety; eventual satisfaction = liveness) and a performance protocol (TokenB broadcasts, TokenM multicasts to predicted sharers). Subsumes snooping and directory (MSI ≈ all/some/none of the tokens).
total order of coherence requests ch. 7: All coherence controllers observe ALL requests in one single order; subsumes every per-block order and eases implementing SC/TSO.
total store order (tso) ch. 4: SC minus the Store→Load ordering rule: legalizes per-core FIFO write buffers; the SPARC/x86 memory model.
transaction buffer entry (tbe) ch. 9: A cache controller's shared buffer entry allocated per in-flight transaction (own or serviced). If all TBEs fill with a core's own requests on every core, nobody can service anyone else: a cache resource deadlock.
transient state ch. 6: A state occurring during a non-atomic transition between stable states; notation XY^Z means "was X, becoming Y, completing when an event of type Z occurs."
update protocol ch. 6: On a write, other copies are updated with the new value instead of invalidated; cheaper subsequent reads but more bandwidth and much harder write atomicity; rarely implemented.
upgrade ch. 8: A coherence request that asks for S-to-M permission without data transfer (the requestor already holds a valid copy). Vulnerable to a race: if a rival GetM is serialized first, the upgrader's copy is invalidated and it needs data after all (Origin: NACK + retry as GetM; ch08 baseline MOSI: OM^AC demotion to IM^AD).
upgrade (upg) ch. 6: Transaction upgrading a block from read-only (Shared or Owned) to read-write (Modified) without a data transfer.
vi protocol ch. 9: The two-state (Valid/Invalid) coherence protocol enabled by write-through caches: a store writes through to the LLC and invalidates all other Valid copies; observing another core's write just clears Valid.
virtual cache ch. 9: A cache accessed with virtual addresses, taking address translation off the hit critical path. Costs: coherence requests (physical addresses) need REVERSE translation, and synonyms can put one physical block in multiple cache locations. Rare today — VIPT (virtually indexed, physically tagged) gets the latency win without the problems.
virtual channels ch. 9: Extra per-switch FIFO queues used at the NETWORK level to break routing deadlocks (e.g., dimension-ordered torus rules) — orthogonal to virtual networks, which separate coherence message classes; each virtual network may contain several virtual channels.
virtual networks ch. 8: Separate physical or logical (virtual) networks per message class — requests, forwarded requests, responses — so one class can never block another, breaking deadlock cycles.
warp ch. 10: Group of GPU threads fetched and decoded together, sharing PC and stack, executing SIMT-style under mask bits (AMD: wavefront). Modern GPUs allow the threads independent scheduling.
weak ordering ch. 5: Dubois et al.'s pioneering relaxed model, later generalized by SC for DRF.
window of vulnerability ch. 7: Without Atomic Requests, the gap between issuing a request and its serialization, during which another core's request may be ordered first and change the block's state.
write atomicity ch. 5: A store becomes logically visible to all other cores at once (its own core may see it early); a.k.a. store atomicity or multi-copy atomicity.
write buffer ch. 4: Per-core FIFO holding committed stores until the cache can accept them; hides store-miss latency.
write serialization ch. 2: All cores observe the writes to a given memory location in the same order.
write-through cache ch. 9: A cache where stores propagate immediately to the next level. Practical only at L1 (bandwidth/power). Buys: a two-state VI protocol, free evictions, an always-current LLC, single-flip-flop state bits, and parity-only fault tolerance (the LLC always holds a valid copy). Complication: TSO write atomicity for multithreaded cores sharing an L1. Used by Sun Niagara and AMD Bulldozer.
x86-tso ch. 4: Sewell et al.'s formal model of the x86 memory model (abstract machine ≡ labeled transition system).
xc ch. 5: The book's eXample relaxed Consistency model: a total memory order exists, but only FENCE-related and same-address orders are enforced, with TSO-style bypassing.