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

32. Shared Memory и race condition между процессами

Общая память: Самый быстрый канал связи между процессами

В иерархии 31. Межпроцессное взаимодействие. IPC общая память (Shared Memory) стоит на абсолютной вершине по скорости передачи данных.

Если обычные каналы связи вроде pipe, сетевого socket или очереди сообщений message queue можно уподобить почтовым службам, где каждое письмо упаковывается в конверт, переносится курьером в здание почтамта (ядро Linux) и распаковывается адресатом, то Shared Memory — это снос перегородки между двумя смежными кабинетами. Оба сотрудника просто кладут один лист бумаги на общий стол между ними. Запись и чтение происходят со скоростью обращений процессора к оперативной памяти (десятки гигабайт в секунду), полностью исключая системные вызовы и копирование данных между User Space и Kernel Space. Два или более процессов получают доступ к одним и тем же физическим страницам RAM через свои виртуальные адресные пространства.

На этой технологии держится фундамент современных высоконагруженных систем: буферные пулы СУБД (InnoDB buffer pool в MySQL, PostgreSQL shared buffers), высокопроизводительные кэши (Redis, Dragonfly), системы высокочастотного трейдинга (HFT), обработка видеопотоков и shared-object библиотеки.

Но в физике и архитектуре компьютеров бесплатных завтраков не бывает: за феноменальную скорость приходится расплачиваться полным отсутствием автоматической координации. Ядро больше не выступает арбитром в дверях. Любая неосторожность превращается в кошмар разработчика: коварный Data Race, повреждение структур данных и трудноуловимые сбои кэш-памяти процессора.

flowchart TD
    subgraph ProcessA["Процесс A (User Space)"]
        VA_A["Виртуальный адрес 0x7fff1000"]
        PT_A["Page Table A (PTE A)"]
    end

    subgraph ProcessB["Процесс B (User Space)"]
        VA_B["Виртуальный адрес 0x00405000"]
        PT_B["Page Table B (PTE B)"]
    end

    subgraph PhysicalRAM["Физическая оперативная память (DRAM)"]
        Frame["Физический фрейм (PFN #0x12a4b)<br/>4096 байт общей памяти"]
    end

    VA_A --> PT_A
    VA_B --> PT_B
    PT_A ==>|"MMU трансляция (Прямой доступ)"| Frame
    PT_B ==>|"MMU трансляция (Прямой доступ)"| Frame

    classDef proc fill:#1e293b,stroke:#38bdf8,stroke-width:2px,color:#f8fafc;
    classDef ram fill:#022c22,stroke:#10b981,stroke-width:2px,color:#f8fafc;

    class ProcessA,ProcessB proc;
    class PhysicalRAM,Frame ram;

Как ОС реализует общую память

В операционной системе Linux исторически сосуществуют два API для создания и монтирования разделяемых сегментов:

  1. System V IPC (shmget, shmat, shmdt) — почтенный стандарт 1980-х годов. Оперирует числовыми идентификаторами сегментов и специальным ключом key_t, который генерируется функцией ftok(). Сегменты System V живут в ядре независимо от процессов и не отображаются в стандартное дерево файлов (управляются утилитами ipcs и ipcrm). В современном мире считается легаси.
  2. POSIX Shared Memory (shm_open, mmap, munmap) — современный, чистый и прозрачный стандарт. Все сегменты разделяемой памяти монтируются в виртуальную файловую систему /dev/shm (высокоскоростная in-memory файловая система tmpfs в RAM).

Под капотом POSIX использует shm_open() для создания файла в /dev/shm, а затем mmap() для отображения этого файла в память процесса. Поскольку shm_open возвращает файловый дескриптор, можно применять ftruncate(), чтобы задать размер сегмента.

Давайте посмотрим на то, как это выглядит в кодовой базе Go:

Go 
package main

import (
    "fmt"
    "os"
    "syscall"
)

func main() {
    // 1. Создаем или открываем сегмент в /dev/shm.
    // В пакете syscall нет обёрток shm_open/shm_unlink: POSIX shared memory — это обычные файлы
    // в tmpfs (/dev/shm), и os.OpenFile делает по сути то же самое.
    f, err := os.OpenFile("/dev/shm/my_shared_seg", os.O_RDWR|os.O_CREATE, 0644)
    if err != nil {
        // production-ready: всегда обрабатываем ошибки
        panic(fmt.Sprintf("open /dev/shm failed: %v", err))
    }
    defer f.Close()
    defer os.Remove("/dev/shm/my_shared_seg") // аналог shm_unlink

    // 2. Устанавливаем размер (например, 4096 байт; аналог ftruncate)
    if err := f.Truncate(4096); err != nil {
        panic(fmt.Sprintf("truncate failed: %v", err))
    }

    // 3. Отображаем в память процесса
    ptr, err := syscall.Mmap(int(f.Fd()), 0, 4096, syscall.PROT_READ|syscall.PROT_WRITE, syscall.MAP_SHARED)
    if err != nil {
        panic(fmt.Sprintf("mmap failed: %v", err))
    }
    defer syscall.Munmap(ptr)

    // ptr теперь указывает на область, видимую другими процессами
    // Работа с ptr требует синхронизации!
    _ = ptr
}

Корень зла: Race Conditions и Data Races

Когда несколько процессов пишут в одну область без синхронизации, возникает Race Condition. Если это приводит к неопределенному поведению из-за чтения/записи без атомарности — это Data Race.

Программисту, пишущему на языке высокого уровня, кажется, что следующая строчка неделима:

C 
// Процесс А и Процесс Б одновременно делают:
counter = counter + 1;

Но процессор оперирует не абстрактными формулами, а конкретными машинными инструкциями. На уровне ассемблера этот простой инкремент разваливается в три независимые инструкции:

  1. LOAD R1, [addr] (прочитать значение из памяти по адресу addr в локальный регистр процессора R1)
  2. ADD R1, R1, 1 (выполнить арифметическое сложение в АЛУ)
  3. STORE [addr], R1 (записать обновленное значение из регистра обратно в память)
sequenceDiagram
    autonumber
    participant PA as Процесс А (Ядро 0)
    participant RAM as Память (counter = 0)
    participant PB as Процесс Б (Ядро 1)

    PA->>RAM: 1. LOAD R1, [counter] (R1 = 0)
    PB->>RAM: 2. LOAD R1, [counter] (R1 = 0)
    Note over PA: 3. ADD R1, 1 (R1 = 1)
    Note over PB: 4. ADD R1, 1 (R1 = 1)
    PA->>RAM: 5. STORE [counter], R1 (Память: counter = 1)
    PB->>RAM: 6. STORE [counter], R1 (Память: counter = 1)
    Note over RAM: Катастрофа! Было 2 инкремента, а результат = 1 (Lost Update)

Если Процесс А прерывается между шагами 1 и 3, а Процесс Б успевает выполнить весь цикл, результат будет counter + 1 вместо counter + 2. Потерянное обновление (Lost Update). В реальном приложении это означает рассинхронизацию балансов пользователей, пропущенные события или повреждение индексов очередей.

Синхронизация на уровне ОС

Чтобы использовать общую память, нужно наложить примитивы синхронизации. В Go стандартный sync.Mutex не работает между процессами, так как он блокируется только в рамках адресного пространства текущего процесса.

Для cross-process синхронизации используются:

  • POSIX Semaphores (sem_open, sem_wait, sem_post) — работают с общей памятью или как именованные объекты. Именованный семафор виден всем процессам в системе через путь в файловой системе.
  • Futexes — низкоуровневый примитив Linux, сочетающий блокировку в User Space с системным вызовом только при конфликте. Fast Userspace Mutex позволяет захватывать свободную блокировку за считанные наносекунды с помощью атомарной инструкции CPU, не беспокоя ядро.
  • Atomic Operations — инструкции процессора (LOCK XADD, CMPXCHG), гарантирующие атомарность на уровне шины/кэша. Аппаратный блок управления кэшем удерживает строку кэша в эксклюзивном владении на время выполнения всей операции Read-Modify-Write.

Mechanical Sympathy: Кэш, MESI и False Sharing

Даже если вы используете атомарные инструкции, производительность общей памяти может быть убита архитектурой CPU.

1. Cache Coherence (MESI Protocol)

Современные CPU имеют локальные кэши L1/L2. Когда два ядра пишут в один кэш-лайн (64 байта), включается протокол MESI (Modified, Exclusive, Shared, Invalid).

  • Ядро 1 пишет в байт 0 кэш-лина. Статус меняется на Modified.
  • Ядро 2 пытается прочитать байт 4. Оно должно инвалидировать свою копию кэш-лина и забрать свежие данные у Ядра 1 через шину.
  • Частые записи в один кэш-лайн вызывают Cache Thrashing (или Cache Line Bouncing), превращая высокоскоростной CPU в улитку, ожидающую согласования по кольцевой шине межъядерной связи.

2. False Sharing (Ложная совместная запись)

Если два процесса/потока пишут в разные переменные, но они попадают в один кэш-лайн (например, struct { int a; int b; }), процессор считает, что происходит конфликт. Он будет постоянно инвалидировать кэш-лайн, хотя данные не пересекаются.

flowchart LR
    subgraph CacheLine["Одна общая Cache Line (64 байта)"]
        direction LR
        VarA["Переменная A (int64, 8B)<br/>Пишет Процесс 1"]
        VarB["Переменная B (int64, 8B)<br/>Пишет Процесс 2"]
        Other["Остальные 48 байт"]
    end

    Core1["Ядро 1 (Процесс 1)"] <-->|"Постоянная инвалидация MESI"| CacheLine
    Core2["Ядро 2 (Процесс 2)"] <-->|"Постоянная инвалидация MESI"| CacheLine

    classDef cl fill:#450a0a,stroke:#f43f5e,stroke-width:2px,color:#f8fafc;
    classDef core fill:#1e293b,stroke:#38bdf8,stroke-width:2px,color:#f8fafc;
    class CacheLine,VarA,VarB,Other cl;
    class Core1,Core2 core;

Решение: Padding (выравнивание по границе кэш-лина). Мы искусственно добавляем пустые байты-заполнители, чтобы разнести независимо изменяемые переменные в разные строки кэша:

Go 
// Go-аналог padding для избежания false sharing
type SafeCounter struct {
    Value int64
    _     [56]byte // padding до 64 байт (размер кэш-лайна)
}

3. Memory Barriers (Fences)

Компилятор и CPU могут переставлять инструкции для оптимизации. mfence (x86) или dmb (ARM) запрещают это, гарантируя порядок операций для других ядер. Атомарные операции в Go (atomic.AddInt64) автоматически генерируют необходимые барьеры. Барьер гарантирует, что все операции записи в store buffer будут сброшены в кэш до того, как начнется выполнение последующих команд.

Go и shared memory: Философия и реальность

Go имеет четкую философию:

"Don't communicate by sharing memory; share memory by communicating." — Кен Томпсон / Роб Пайк

Это означает, что горутины должны обмениваться данными через каналы (chan), а не через общую память. Это устраняет Data Race на уровне языка и делает код безопасным.

Но в реальности:

  1. Горутины внутри одного процесса действительно делят память. sync.Mutex, atomic пакет и unsafe.Pointer работают быстро, но требуют дисциплины.
  2. Cross-process shared memory в Go поддерживается через syscall.Mmap или golang.org/x/sys/unix. Однако синхронизация требует внешних примитивов (semaphore, futex).
  3. Race Detector (go run -race) внедряет Instrumentation на этапе компиляции и отслеживает все чтения/записи. Он работает только в рамках одного процесса. Для cross-process отладки нужны valgrind или helgrind.

Ловушки и типичные вопросы на интервью

Ловушка / Вопрос Пояснение
Data Race vs Deadlock Data Race — неопределенное поведение из-за асинхронных доступов к памяти. Deadlock — состояние, где процессы ждут друг друга бесконечно. Data Race часто приводит к невоспроизводимым крашам, Deadlock — к зависанию.
Как обнаружить Race Condition? go run -race (компилятор + runtime). Для cross-process: valgrind --tool=helgrind, clang -fsanitize=thread.
Почему mmap быстрее read/write? read/write вызывает копирование данных: User Buffer -> Kernel Buffer -> Socket/Disk -> Kernel Buffer -> User Buffer. mmap убирает копирование, оставляя только один переход в ядро для установления отображения.
Copy-On-Write и общая память Если вы mmap-ите файл с MAP_PRIVATE, изменения не видны другим процессам и не сохраняются на диск. Для общей памяти всегда MAP_SHARED. CoW экономит память при fork(), но не при mmap для IPC.
Что такое futex? Fast Userspace Mutex. Сначала проверяет переменную в User Space (без syscall). Если свободна — сразу захватывает. Если занята — делает futex() syscall, чтобы уснуть в ядре. Основа sync.Mutex в Go.

Итог

  1. Общая память — это скальпель, а не молоток. Она дает максимальную пропускную способность и минимальную задержку, но перекладывает всю ответственность за консистентность на разработчика.
  2. Понимание того, как виртуальная память отображается на физическую RAM через PTE и PFN, как работает аппаратный протокол MESI и почему возникает False Sharing, отличает Senior-инженера от Middle.
  3. В Go общая память используется точечно, в обход классической философии языка, когда производительность критична. В остальных случаях каналы и context остаются идиоматичным выбором.
  4. Межпроцессная синхронизация требует внешних инструментов ОС: именованных семафоров (sem_open), фьютексов (futex) или аппаратно поддержанных атомарных инструкций с барьерами памяти.

В следующей статье мы разберем, как именно ОС реализует примитивы синхронизации, которые мы упоминали: 33. Mutex, Semaphore, Spinlock на уровне ОС, чтобы закрыть гештальт по аппаратным и программным механизмам блокировок.