Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • Cache Coherency Glossary
  • The Shared Course Model
  • Cache Coherency Revision Sheet
  • Why Coherence Exists8
  • States and Protocols12
  • Transactions12
  • Races and Controller Design8
  • Progress and the Fabric16
  • Ordering and Synchronization12
  • Performance and Scalability12
    • False Sharing
      • True Versus False Sharing
      • Counting Coherence Traffic
      • Padding and Data Layout
      • Finding False Sharing
    • Directory Capacity and Sharers
    • Hotspots and Placement
  • Real Protocols12
  • SoC Integration12
  • Power, Clocking and Reliability12
  • Verification12
  • Debug and Bring-up12
  • Interview and Design Review17
  • Capstone: A Coherent Model Lab5
Loading lesson

‹False Sharing
  1. Topics
  2. Cache Coherency
  3. Performance and Scalability
  4. False Sharing
  5. True Versus False Sharing

Part 7 · Performance and Scalability · All levels

True Versus False Sharing

Identify whether repeated transfers protect shared logical state or unrelated fields placed together.

Why does my private counter keep moving between cores?

A private software field need not occupy a private coherence line. Extend the course model with two aligned eight-byte words: X at byte offset 0 and Y at offset 8 of the same 64-byte line. Both start at 0 with no cached copies. Use MESI. C0 writes only X and C1 writes only Y. They share a permission unit without sharing a logical variable: false sharing.

Independent access pattern

Logical sharing

Permission consequence

C0 and C1 update X

True sharing of X

Writes to the same line require exclusive permission.

C0 updates X, C1 updates neighbouring Y

False sharing

The same permission transfers despite distinct fields.

C0 updates X, C1 updates Y in another line

Separate writable data

Each can retain its own line's write permission.

Classification checks the physical line, then whether any core writes, then whether the cores need the same logical data.
Address overlap alone is not enough: write activity comes first, then the logical data relationship decides true or false sharing.

The exclusive-permission transfer itself is the trace in Three-Hop Versus Four-Hop: C0 holds the line in M and C1 asks for write permission. It is not redrawn here. What this lesson adds is the second word. The line carries X and Y together, so every transfer must preserve every word. If C0 writes X = 1 before C1 writes Y = 1, the final line must contain both 1s. Refilling the line from stale memory and keeping only C1's Y would be a correctness failure, not false-sharing overhead.

The snapshots below are settled states after each completed store (MESI, X at offset 0, Y at offset 8 of one line, both starting at 0). The whole line moves with the permission, and memory stays 0 because nothing has been written back.

After

C0 state / value

C1 state / value

H

Memory

Newest data

Start

I / -

I / -

U

memory = 0

Memory: X = 0, Y = 0

C0 stores X = 1

M / X = 1, Y = 0

I / -

exclusive(C0)

memory = 0

C0: X = 1, Y = 0

C1 stores Y = 1

I / -

M / X = 1, Y = 1

exclusive(C1)

memory = 0

C1: X = 1, Y = 1

The false-sharing label explains unnecessary communication for this algorithm. It does not claim every transfer is slow or give a cycle estimate. Batching writes may reduce changes of exclusive holder even when addresses stay together. Padding changes the permission relationship; batching changes the access schedule.

Before proposing either fix, record byte offsets, write frequency, core placement and the interval of interest. A read-only neighbouring field can also be repeatedly invalidated by a writer, even though the alternating two-writer counter example is easier to count.

Common pitfall

Calling every hot shared line false sharing. A lock word or shared queue index can be true sharing and cannot become private merely by adding unused bytes.

Interview

Draw two words within one 64-byte line. Explain why changing either word requires permission for the whole line and why all neighbouring values must survive the transfer.

Check yourself Does a stale return of X after moving the line to write Y count as an expected performance cost?

No. False sharing increases legal communication. Losing the newest X while preserving only Y violates the data-value obligation.

Related topics

  • Shared course model

  • Count the same schedules

Previous

74 / 167

Next: Counting Coherence Traffic

Up next

Up nextCounting Coherence Traffic

Sign in to save progress

Practice this lessonReport an error

See also

  • Padding and Data Layout
  • Finding False Sharing