Модуль 1 ⏱ ~30 мин чтения 📐 2 Mermaid диаграмм

20. Многоядерные процессоры и Cache Coherence

В предыдущих главах (18. Кэши CPU. L1, L2, L3 и Cache Line и 19. Ассоциативность кэша, Prefetching и Cache Miss) мы подробно изучили, как вычислительное ядро ускоряет свою работу с помощью локального кэша L1. Если бы наш компьютер состоял всего из одного ядра, на этом повествование о кэшах можно было бы триумфально завершить.

Однако эра одноядерных процессоров закончилась еще в середине 2000-х годов, когда инженеры уперлись в так называемую «тепловую стену» (Power Wall). Современные серверы, на которых развернуты наши Go-микросервисы, несут на борту 16, 32, 64, а нередко и 128 физических ядер. Планировщик Go (модель GMP: G, M, P) непрерывно жонглирует тысячами горутин, распределяя их по всем доступным ядрам операционной системы.

И здесь мы сталкиваемся с фундаментальной угрозой для здравого смысла программиста.

Представим элементарный сценарий:

  1. Горутина A исполняется на Ядре 1. Она читает глобальную переменную Counter (изначально равную 0) из оперативной памяти в свой персональный кэш L1.
  2. Горутина B исполняется на Ядре 2. Она делает то же самое — читает Counter в свой локальный кэш L1.
  3. Горутина A выполняет операцию Counter++. Новое значение 1 записывается в кэш L1 Ядра 1.

Что теперь лежит в кэше L1 Ядра 2? Там по-прежнему покоится старое значение 0!
Данные в системе рассинхронизировались. Если Ядро 2 прямо сейчас прочитает переменную Counter, оно получит устаревший мусор и примет неверное бизнес-решение.

flowchart TD
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    subgraph Problem["Проблема рассинхронизации локальных кэшей"]
        direction TB
        subgraph Core1["Ядро 1"]
            L1_1["Кэш L1 (Ядро 1)<br>Counter = 1 (Свежее!)"]
        end
        subgraph Core2["Ядро 2"]
            L1_2["Кэш L1 (Ядро 2)<br>Counter = 0 (Устарело!)"]
        end
        RAM["Оперативная память (DRAM)<br>Counter = 0"]

        Core1 -.->|"Запись: Counter++"| L1_1
        Core2 -.->|"Чтение: ожидает 1, видит 0!"| L1_2
        L1_1 -.-> RAM
        L1_2 -.-> RAM
    end

Чтобы этот кошмар не сломал многопоточное программирование, создатели процессоров разработали аппаратный протокол синхронизации, который делает работу распределенных кэшей абсолютно прозрачной для разработчика. Этот фундамент называется Когерентностью кэшей (Cache Coherence).

Аппаратная магия: Протокол MESI

Процессор не позволяет локальным кэшам жить изолированной жизнью. Все кэши L1 и L2 непрерывно связаны высокоскоростными коммуникационными каналами (кольцевой шиной Ring Bus или двумерной сеткой Mesh Interconnect).

Они непрерывно обмениваются служебными сообщениями по протоколам когерентности. Базовой моделью когерентности в процессоростроении стал протокол MESI (также известный как протокол Иллинойса). Реальные процессоры используют его расширения: MESIF у Intel (добавлено состояние Forward — какой именно из кэшей, держащих общую строку, отвечает на запрос) и MOESI у AMD (состояние Owned позволяет отдать изменённую строку другому ядру, не записывая её сразу в RAM). Для понимания идеи достаточно MESI.

Название протокола представляет собой акроним четырех дискретных состояний, в которых может находиться каждая 64-байтная кэш-линия:

  • M (Modified — Изменена):
    Данная кэш-линия присутствует только в этом локальном кэше L1/L2. Текущее ядро изменило её содержимое. Данные в кэше новее, чем в медленной оперативной памяти DRAM. Ядро является единоличным «грязным» владельцем строки (Dirty Owner).
  • E (Exclusive — Эксклюзивна):
    Кэш-линия присутствует только в этом локальном кэше, но она «чистая» (ее байты на 100% совпадают с данными в оперативной памяти). Ядро может в любой момент записать в неё данные, мгновенно переведя в статус M, никого не предупреждая по шине.
  • S (Shared — Общая, разделяемая):
    Кэш-линия загружена в локальные кэши сразу нескольких ядер. Данные везде чистые и идентичны оперативной памяти. Любое ядро имеет право молниеносно читать эти байты из своего кэша, но ни одно ядро не имеет права изменять эту строку без предварительного оповещения остальных!
  • I (Invalid — Недействительна):
    Кэш-линия считается пустой или аннулированной. Данные в ней устарели, так как другое ядро перетерло эту память. Если процессору понадобится этот адрес, он обязан проигнорировать эту строку и запросить ее заново по шине.
flowchart TD
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    I["I (Invalid)<br>Строка пуста или устарела"]
    E["E (Exclusive)<br>Только у нас, чистая с RAM"]
    S["S (Shared)<br>У нескольких ядер, только чтение"]
    M["M (Modified)<br>Только у нас, изменена (грязная)"]

    I -->|"Чтение: ни у кого больше нет"| E
    I -->|"Чтение: кто-то уже держит"| S

    E -->|"Другое ядро читает"| S
    E -->|"Локальная запись (Local Write)"| M

    S -->|"Другое ядро пишет (получен Invalidate)"| I
    S -->|"Локальная запись (рассылка Invalidate)"| M

    M -->|"Другое ядро читает (сброс в RAM/L3)"| S
    M -->|"Другое ядро пишет (сброс + Invalidate)"| I

Как это работает в динамике

Вернемся к нашему примеру с горутинами и переменной Counter:

  1. Чтение Ядром 1: Ядро 1 запрашивает строку с адресом Counter. Ни в одном другом кэше этой строки нет. Ядро загружает данные, линия помечается как E (Exclusive).
  2. Чтение Ядром 2: Ядро 2 отправляет в шину запрос на чтение Counter. Ядро 1 отслеживает трафик шины (аппаратный механизм Snooping). Оно сообщает: «Эта строка есть у меня». Контроллеры обоих ядер переводят свои локальные кэш-линии в статус S (Shared).
  3. Запись Ядром 1 (Counter++): Ядро 1 хочет модифицировать значение. Оно видит, что строка находится в статусе S. Процессор не может просто записать в общую строку: сначала нужно получить на неё эксклюзивное право (запрос RFO — Read For Ownership). Сама запись при этом не «блокирует» весь конвейер: ядро кладёт её в store buffer и продолжает исполнять другие инструкции, а владение линией запрашивается асинхронно.
    • Ядро 1 выставляет на шину широковещательный сигнал: Invalidate Counter.
    • Ядро 2 ловит этот сигнал и принудительно переводит статус своей копии в I (Invalid).
    • Ядро 2 возвращает сигнал подтверждения: Invalidation Acknowledge (ACK).
    • Получив ACK, Ядро 1 переводит свою линию в статус M (Modified) и перезаписывает байт на значение 1.

Теперь Ядро 1 владеет самой свежей версией данных. Если Ядро 2 захочет снова прочитать Counter, оно обнаружит статус I (Invalid), получит кэш-промах (Coherence Miss) и запросит актуальную строку прямо у Ядра 1.

Mechanical Sympathy: Цена Invalidate-шторма

Создатели процессоров сотворили чудо: программист на Go может быть уверен, что для одного и того же адреса все ядра видят единую историю записей и не «откатываются» назад по ней (а вот когда именно чужая запись станет видна, зависит от store buffer и очередей инвалидации — об этом ниже, в разделе про консистентность). Но законы физики обойти нельзя. За эту гарантию приходится платить производительностью.

Сравним стоимость операций:

  • Чтение общих данных (Shared) абсолютно бесплатно: Если 100 горутин на разных ядрах одновременно читают неизменяемый глобальный конфиг, все их кэши L1 находятся в статусе S. Никакого трафика по шине нет, доступ занимает 1 наносекунду.
  • Запись в общую память — колоссальный аппаратный тормоз:
    Когда вы вызываете в Go атомарную операцию atomic.AddInt64(&counter, 1) или захватываете мьютекс sync.Mutex, ядро генерирует инструкцию с префиксом LOCK (например, LOCK XADDQ). Вопреки старой легенде, она блокирует не всю шину памяти, а только нужную кэш-линию (полная блокировка шины — лишь в редком случае «split lock», когда операнд пересекает границу линии).

Ядро обязано разослать Invalidate-сигналы по межъядерной сети, дождаться ответов ACK от всех остальных ядер и только после этого применить запись. Если за линию борются несколько ядер, эта процедура занимает порядка 40–80 наносекунд — за это время конвейер мог бы выполнить сотни полезных инструкций! (Без конкуренции, когда линия уже принадлежит нашему ядру, атомарная операция стоит гораздо дешевле — порядка нескольких наносекунд: по нашему замеру на Go 1.27.1 atomic.Add — около 3.7 нс.)

Cache Line Ping-Pong (Пинг-понг кэш-линий)

Если несколько горутин на разных физических ядрах в цикле инкрементируют одну и ту же переменную counter, возникает катастрофический сценарий:

  1. Ядро 1 объявляет строку M, Ядро 2 получает I.
  2. Через долю наносекунды Ядро 2 хочет записать свое значение: оно шлет Invalidate Ядру 1, заставляя его сбросить статус в I, и забирает строку себе в M.
  3. Ядро 1 тут же делает то же самое в ответ.

Кэш-линия с дикой скоростью мечется между ядрами процессора по межъядерной шине. Процессор тратит 99% тактов не на сложение чисел, а на разрешение конфликтов протокола MESI и ожидание подтверждений ACK. Пропускная способность падает в десятки раз.

Когерентность vs Консистентность (Память не багует)

Начинающие инженеры часто путают два фундаментальных термина, считая их синонимами. Давайте раз и навсегда разделим их:

Концепция За что отвечает Аппаратный уровень
Когерентность (Cache Coherence) Поведение одной ячейки памяти. Гарантирует, что все ядра видят единую историю изменений по конкретному адресу. Протокол MESI исключает чтение «разошедшихся» копий одной и той же ячейки (в смысле единой истории записей по этому адресу). 100% реализуется транзисторами кэш-контроллеров процессора.
Консистентность / Модель памяти (Memory Consistency) Взаимный порядок операций над разными переменными (например, порядок записи во флаг готовности и данные). Определяется архитектурой процессора (x86 TSO против ARM Weak Ordering) и моделью памяти языка Go.

Протокол MESI гарантирует: память никогда не «врёт» об одной конкретной переменной. Если Ядро 1 записало число в counter, Ядро 2 не сможет «разойтись» с ним в истории записей этого адреса: после того как запись Ядра 1 стала глобально видимой, старое значение из своего L1 оно уже не прочитает. (Момент, когда запись становится видимой, — вопрос консистентности и store buffer, а не когерентности.)

Итог

  1. Когерентность кэшей (Cache Coherence) — аппаратная система поддержания синхронности локальных кэшей всех ядер процессора.
  2. Протокол MESI управляет состояниями 64-байтных строк: M (Modified — изменена локально), E (Exclusive — только у нас, чистая), S (Shared — разделяется, только чтение), I (Invalid — аннулирована).
  3. Чтение общих данных масштабируется великолепно: сотни ядер могут одновременно опрашивать свои L1 со скоростью 1 нс.
  4. Запись в общие данные порождает межъядерный Invalidate-шторм. Ядро замирает на десятки наносекунд в ожидании подтверждений ACK от остальных ядер.
  5. Примитивы синхронизации Go (sync.Mutex, atomic.AddInt64, счетчик в sync.RWMutex) внутри выполняют запись, провоцируя переход линий в статус Modified и вызывая эффект Cache Line Ping-Pong.

Но протокол MESI скрывает еще более опасную ловушку. Он оперирует не отдельными переменными вроде int32 или bool, а целыми 64-байтными кэш-линиями.

Что произойдет, если Ядро 1 пишет в переменную A, а Ядро 2 пишет в совершенно не связанную переменную B, но компилятор разместил их в памяти бок о бок в пределах одних и тех же 64 байт? Процессор посчитает, что ядра конфликтуют за один ресурс, и уничтожит производительность вашего параллельного кода!

С этим коварнейшим эффектом мы встретимся лицом к лицу в следующей главе: 21. False Sharing и Cache Line Contention.