Краткий ответ

Изменение обычной глобальной переменной в одном процессе не изменит её значение в другом процессе. У каждого процесса собственное адресное пространство, поэтому процессы работают с независимыми копиями памяти.

Обмен данными возможен только через специальные механизмы: очереди, каналы, прокси multiprocessing, общую память, файлы или внешнее хранилище.

Исторический контекст

Процессы — базовый механизм операционных систем для изоляции программ и распределения вычислений между ядрами. Такая изоляция повышает надёжность: сбой или изменение памяти одного процесса не должны напрямую повреждать память другого.

Модуль multiprocessing использует эту модель, позволяя запускать Python-код в отдельных процессах. Это даёт независимую память, но одновременно требует явного обмена данными и синхронизации.

Постановка проблемы

Предположим, главный процесс хранит состояние в глобальном словаре, а рабочий процесс должен обновить этот словарь. Интуитивное ожидание, что после завершения рабочего процесса главный увидит изменения, ошибочно.

import multiprocessing as mp

value = 0

def worker():
    global value
    value = 42

if __name__ == '__main__':
    process = mp.Process(target=worker)
    process.start()
    process.join()
    print(value)  # 0

Рабочий процесс изменяет свою копию value. После его завершения эта копия уничтожается, а value в главном процессе остаётся равной 0.

Подробное решение

При создании процесса операционная система предоставляет ему отдельное виртуальное адресное пространство. Одинаковые адреса памяти в разных процессах не означают одну и ту же физическую область памяти.

При запуске через fork дочерний процесс первоначально получает логическую копию памяти родителя. Благодаря механизму copy-on-write страницы физически могут быть общими до первой записи, но изменение страницы создаёт отдельную копию. Поэтому изменения дочернего процесса не возвращаются родителю.

При запуске через spawn создаётся новый интерпретатор Python, который импортирует необходимый код заново. Общая глобальная переменная в этом случае также не является общей: процессы получают независимые состояния.

Для передачи результата обычно используют возврат значения из Pool или ProcessPoolExecutor, Queue либо Pipe. Для совместно изменяемого состояния доступны Manager, Value, Array и shared_memory, но они требуют анализа синхронизации и часто имеют дополнительные накладные расходы.

Важно различать передачу данных и разделяемое состояние. Передача результата через очередь обычно проще и безопаснее: рабочий процесс формирует результат, а главный процесс применяет его у себя. Общая память может быть быстрее для больших массивов, но требует контроля гонок, согласованности данных и времени жизни объектов.

Ситуация из практики

Сервис обрабатывает документы несколькими процессами и должен вести общий счётчик ошибок. Размещение счётчика в глобальной переменной приводит к неверному результату: каждый процесс увеличивает собственную копию, а главный процесс не видит эти изменения.

Рассматривались три варианта. Manager предоставляет удобный общий объект, но каждое обращение к нему проходит через прокси и может стать узким местом. Общая память эффективна для числовых структур и больших буферов, но требует явной синхронизации и более сложного контроля доступа. Передача частичных счётчиков через Queue добавляет обмен сообщениями, зато позволяет каждому процессу работать со своим локальным состоянием без общей изменяемой памяти.

Выбран вариант с локальной агрегацией и отправкой итогов в очередь главному процессу. Главный процесс последовательно суммирует полученные значения, поэтому состояние имеет одного владельца, а риск гонок минимален. Такой подход обычно предпочтительнее для счётчиков и результатов пакетной обработки; общую память стоит выбирать только при доказанной необходимости совместного доступа к большим объёмам данных.

Что кандидаты часто упускают

Если процесс создаётся через fork, разве глобальные переменные не являются общими?

Нет. При fork дочерний процесс получает состояние, существовавшее на момент создания, но не совместную изменяемую память. Сначала страницы могут физически использоваться совместно, однако после записи применяется copy-on-write, и изменение становится локальным для записавшего процесса. Поэтому дочерний процесс видит начальное значение, но последующие изменения не синхронизируются с родителем.

Каким способом процессы могут безопасно обмениваться изменениями?

Для отдельных результатов подходят Queue, Pipe, результаты Pool или ProcessPoolExecutor. Для совместного состояния можно использовать прокси Manager, примитивы Value и Array с блокировками либо shared_memory с самостоятельной синхронизацией.

Выбор зависит от характера данных. Сообщения хорошо подходят для схемы «рабочий процесс вычисляет — владелец состояния применяет», а общая память оправдана, когда копирование больших данных слишком дорого и команда готова управлять конкурентным доступом.

Почему один и тот же код может по-разному запускаться при fork и spawn?

fork наследует состояние родительского процесса на момент создания, тогда как spawn запускает новый интерпретатор и импортирует код заново. Поэтому код создания процессов должен быть защищён условием if __name__ == '__main__':, иначе при spawn импорт модуля может снова создать процессы рекурсивно.

Кроме того, объекты и глобальные значения, доступные после fork, могут отсутствовать или иметь другое состояние при spawn. На переносимый код нельзя опираться на случайное наследование памяти: начальные данные лучше явно передавать процессу, а результаты — получать через предусмотренный механизм обмена.