Блог

Предположим, я использую a multiprocessing.Manager для создания двух общих объектов и передачи их подпроцессу, который начинает запись в эти объекты:

 manager = multiprocessing.Manager()
a = manager.list()
b = manager.list()
subprocess = MyProcess(a,b)
subprocess.start()  # writing to a and b starts here

# inspect a and b - in what order will changes appear?
 

Есть ли способ убедиться, что порядок, в котором эти записи отражаются в родительском процессе, совпадает с порядком, в котором записи выполняются в подпроцессе? Что делать, если я register() класс с двумя членами, и подпроцесс вносит изменения в эти два члена?

Есть ли ссылка, которая отвечает на эти вопросы «порядка операций» в более общем плане? (Я не смог найти это в документах). Например: что, если мы создадим второй подпроцесс subprocess_2 , который также будет выполнять некоторую запись и чтение a , и b — что мы можем сказать об изменениях порядка, которые будут отражены в родительском и в subprocess_2 ?

ПРОСТОЙ, ПОДРОБНЫЙ ПРИМЕР: Следуя примеру Booboo, если myProcess (подкласс multiprocessing.Process ) реализует run() так:

 def run(self) :
    a.append(1)
    b.append(2)
 

затем, если мы подождем достаточно долго, мы знаем, что родительский процесс увидит a == [1] и b == [2] . Вопрос в том, какие возможные состояния мы можем видеть между ними. Если в менеджере есть какая-то глобальная синхронизация, мы сможем увидеть только следующие пары значений для a,b : [],[] , [1],[] или конечного состояния [1],[2] . Но без такой синхронизации мы можем мельком [],[2] увидеть (если, например, сообщение о добавлении к b достиг родителя быстрее, или порядок опроса очередей не такой, как мы ожидаем (чего мы ожидаем?)). Я надеялся, что мне не придется просматривать исходный код (который также может измениться в будущих версиях), а скорее получить общую гарантию, если она есть. Надеюсь, это прояснит вопрос.

В показанном примере вы имеете дело с управляемым списком. Этот список существует в процессе, который создается при выполнении manager = multiprocessing.Manager() . Переменные a и b на самом деле являются прокси-объектами. Когда методы вызываются на этих прокси-серверах, выполняется вызов удаленного метода (механизм связи представляет собой сокет под Linux и именованный канал под Windows) из адресного пространства одного процесса в адресное пространство SynchManager ( multiprocessing.SyncManager будучи классом, который создается вызовом multiprocessing.Manager() ), и фактический метод выполняется потоком, запущенным в адресном пространстве SyncManager, прослушивающим соединение сокета, и не будет отвечать на соединение (возвращаться обратно вызывающему), пока вызов метода не будет завершен.

Обновить

Основываясь на обновленном вопросе OP, возможные состояния списков a и b расположены в порядке времени:

1. a -> [], b -> []
2. a -> [1], b -> []
3. a -> [1], b -> [2]

Других возможных состояний нет, потому что вызов a.append(1) будет заблокирован до тех a пор, пока список не будет дополнен значением 1 . Представьте себе следующий код:

 a.append(1)
# How can the following assertion fail?
# Who would implement a list in such a way where this could fail?
assert(1 in a)
b.append(b)