Does coherent memory remove the need for locks?

No. Locks and other synchronization operations can provide application-level coordination that coherence alone does not supply.

Must a reader always fetch from main memory?

No. A coherence protocol can arrange for a valid value to come from another cache or another level of the hierarchy.

Can different variables interfere with performance?

Yes. If they share a cache line, independent writes may cause ownership transfers, a situation called false sharing.

AI Glossary / Data engineering and architecture / Intermediate

Memory coherence

Definition

Memory coherence is the property that accesses to the same shared memory location behave according to a consistent ordering, even when processors hold cached copies. It prevents those copies from acting as permanently independent versions of one location. It is closely associated with cache coherence and is narrower than the memory consistency model governing ordering across different locations.

What it means

Processors use caches to avoid fetching every value from slower memory. If several cores cache the same location, a write creates a coordination problem: another core must not keep using an obsolete copy as though the write had never happened.

Coherence supplies rules for this shared location. It does not mean that every cache always contains identical bytes at the same physical instant. Some copies can be invalid, and communication takes time. Nor does coherence alone make an application free of races. Programmers still need synchronization appropriate to their language and platform when multiple threads communicate through memory.

How it works

A coherent system tracks which cached copies may be read or modified. A write may require ownership of the relevant cache line and invalidation of other copies. A later reader obtains data through the permitted path, potentially from another cache rather than directly from main memory.

Implementations differ. Snooping mechanisms observe coherence traffic, while directory mechanisms track sharers and direct messages to the relevant participants. Both involve communication and state transitions, not instantaneous broadcasting of every changed byte.

The memory consistency model addresses the broader question of which orders may be observed across multiple locations. Correct publication of a data structure and its ready flag therefore requires more than knowing that each location is individually coherent. Use the language's defined synchronization operations instead of inferring guarantees from a cache diagram.

Three practical examples

1. Shared counters: Developers investigating an incorrect total distinguish cache coherence from the atomicity of incrementing a variable. Coherent reads and writes do not automatically combine a read, addition and write into one indivisible operation.

2. Parallel analytics: Engineers assign neighboring counters to different threads and notice unexpected traffic between cores. The counters can occupy one cache line, so unrelated updates still interact through the coherence mechanism.

3. AI serving: A service publishes updated model metadata to worker threads. The design uses supported synchronization to establish when the complete metadata is available, rather than relying on a flag and assuming coherent hardware settles every ordering question.

Think of it this way

Imagine a shared notice whose photocopies are held in several offices. When an authorized change occurs, the offices need rules for retiring old copies and obtaining the current version. A copy marked invalid cannot remain an authoritative notice.

Memory has precise operations and ordering rules. It does not depend on people agreeing on meaning, and it does not promise that every office receives a physical replacement at the same instant.

Worked example

Consider two increments on one shared counter, initially zero. Each increment is implemented as separate read, add and write steps.

Thread A reads zero. Thread B also reads zero. A computes one and writes one. B computes one and writes one. The final counter is one, although two increments were intended.

Nothing in this sequence requires incoherent caches. The writes to that location can be consistently ordered, yet the application loses an update because the larger read-modify-write operation was not protected.

An appropriate atomic increment or lock can address that problem under the programming environment's rules. This is a conceptual interleaving, not a recommendation to write unsynchronized ordinary variables in a language where doing so causes undefined behavior. The example shows why a hardware property and an application correctness requirement must be analyzed separately.

Illustrative case study

Fictional case: Coherent Meadow runs a parallel image-processing pipeline. Each worker updates its own progress counter, but throughput deteriorates when more workers are added. The team initially assumes the shared-memory machine is failing to keep its caches coherent.

Profiling instead points to frequent ownership transfers involving a line containing several workers' counters. The coherence mechanism is doing its job; the data layout makes it expensive. Engineers experiment with separating frequently written counters and compare representative workloads.

They also retain synchronization for the final result collection. Improving cache-line placement is a performance change, not a replacement for correct communication between threads. This fictional case promises no speedup.

Common misconceptions and mistakes

Coherence is not the same as sequential consistency. The latter specifies a stronger style of ordering across operations, while coherence focuses on a location.

The newest value is not defined simply by looking at wall-clock timestamps on different cores. Architectural ordering and synchronization establish what observations are permitted.

A coherent CPU memory system does not automatically make every device or accelerator access coherent in the same way. Interfaces and platform documentation matter.

Finally, more coherence traffic is not necessarily evidence of a defect. It may be the cost of frequent sharing or false sharing in an otherwise correctly functioning system.

Business use

Memory coherence matters when evaluating the correctness and scaling of shared-memory software. For a business application, translate the issue into practical questions: are updates lost, are threads communicating through supported operations, and is data sharing limiting throughput?

Separate correctness tests from performance measurements. A faster run is not evidence that a race has disappeared, and a correct result in a small test does not establish that all schedules are safe. Developers need to understand both the memory model and workload.

Check your understanding

Two coherent cores both read zero and then each writes one while attempting separate increments. Does a final value of one prove coherence failed?

Answer: No. It can reveal a missing atomic read-modify-write operation. Coherence does not automatically make the multi-step increment indivisible.

Related terms

Cache coherence
Synchronization
Shared memory
memory consistency model
atomic operation
false sharing
cache line
directory protocol

Learn next

Learn atomic operations next to separate indivisible updates from ordinary loads and stores. Then study memory consistency and publication patterns. Finally, examine false sharing with a profiler to see how correct sharing can still cause expensive communication.

Sources

Carnegie Mellon, Memory Consistency, Spring 2020: https://www.cs.cmu.edu/afs/cs/academic/class/15418-s20/www/lectures/14_consistency.pdf — Read for coherence versus consistency and ordering boundaries.

Carnegie Mellon, Directory-Based Cache Coherence II, Spring 2012: https://www.cs.cmu.edu/afs/cs/academic/class/15418-s12/www/lectures/13_directorycoherence2.pdf — Read for directory communication mechanisms. Examples and fictional case are original conceptual exercises.

Previous: Memoization Next: Memory-level parallelism