Ответ.

В Python при работе с потоками объекты в памяти доступны сразу всем потокам без копирования. Однако при работе с процессами через multiprocessing стандартные питоновские объекты (например, списки, словари) передаются между процессами через сериализацию (обычно через pickle), и каждый процесс получает свою копию объекта. Изменение объекта в одном процессе не отражается на копии в другом процессе.

Ключевые отличия:

Многопоточность (threading): Все потоки работают в общем адресном пространстве. Любые объекты (в том числе вложенные коллекции) разделяются.
Многопроцессность (multiprocessing): Каждый процесс имеет свою память; объекты передаются через сериализацию. Для обмена между процессами должны использоваться специальные структуры, например, multiprocessing.Manager().dict().

Пример:

# Многопроцессность
from multiprocessing import Process, Manager

def worker(d):
    d['a'] = 42

if __name__ == '__main__':
    # Простой dict не работает между процессами
    managed_dict = Manager().dict()
    p = Process(target=worker, args=(managed_dict,))
    p.start(); p.join()
    print(managed_dict['a'])  # 42

Если бы использовался обычный dict, изменения в процессе были бы не видны в главном процессе.

Вопрос с подвохом.

В каких случаях редактирование обычного списка (list) в одном процессе отразится в другом процессе?

Ответ:

Никогда, если работаете с multiprocessing. Обычные объекты Python не разделяются между процессами. Для разделения нужно использовать специальные примитивы — объекты Manager (например, Manager().list(), Manager().dict()), которые синхронизируют состояние между процессами.

Примеры реальных ошибок из-за незнания тонкостей темы.

История

Команда разработчиков веб-краулера инициализировала очереди заданий как списки и делила их между процессами через multiprocessing. Задания "терялись", потому что процессы не видели обновлений друг друга. Исправили на использование Manager().list().

История

В аналитическом сервисе логи пытались собирать во вложенные dict внутри потоков. При высоконагруженном сценарии это привело к race condition и повреждению данных из-за отсутствия блокировок.

История

В ETL-сервисе при попытке собрать собранные во время этапа обработки объекты данных во множество процессов обнаружили дублирование/потерю данных: программисты не учитывали, что каждый процесс работал со своей копией структуры, а не с общей.