Почему этот небольшой фрагмент зависает при использовании многопроцессорной обработки с maxtasksperchild, numpy.random.randint и numpy.random.seed?

Оказывается, это происходит из-за ошибочного взаимодействия Python между threading.Lock и multiprocessing.

np.random.seed и большинство функций np.random.* используют threading.Lock для обеспечения потокобезопасности. Функция np.random.* генерирует случайное число, а затем обновляет начальное число (распределенное по потокам), поэтому необходима блокировка. См. np.random.seed. и cont0_array (используется np.random.random() и другие).

Теперь, как это вызывает проблему в приведенном выше фрагменте?

В двух словах, фрагмент зависает, потому что состояние threading.Lock наследуется при разветвлении. Таким образом, когда дочерний блок разветвляется в то же время, когда блокируется родитель (в np.random.randint(10)), дочерний блокируется (в np.random.seed).

@njsmith объясняет это в этой проблеме github https://github.com/numpy/numpy/issues/9248#issuecomment-308054786

multiprocessing.Pool порождает фоновый поток для управления рабочими процессами: >https://github.com/python/cpython/blob/aefa7ebf0ff0f73feee7ab24f4cdcb2014d83ee5/Lib/multiprocessing/pool.py#L170-L173

Он зацикливается в фоновом режиме, вызывая _maintain_pool: github.com/python/cpython/blob/aefa7ebf0ff0f73feee7ab24f4cdcb2014d83ee5/Lib/multiprocessing/pool.py#L366

Если рабочий процесс завершается, например, из-за ограничения maxtasksperchild, то _maintain_pool вызывает _repopulate_pool: ="nofollow noreferrer">https://github.com/python/cpython/blob/aefa7ebf0ff0f73feee7ab24f4cdcb2014d83ee5/Lib/multiprocessing/pool.py#L240

А затем _repopulate_pool разветвляет несколько новых рабочих процессов, все еще находящихся в этом фоновом потоке: ">https://github.com/python/cpython/blob/aefa7ebf0ff0f73feee7ab24f4cdcb2014d83ee5/Lib/multiprocessing/pool.py#L224

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

Простой обходной путь здесь — не использовать fork с многопроцессорной обработкой. Если вы используете методы запуска spawn или forkserver, это должно исчезнуть.

Для правильного исправления .... тьфу. Я думаю, нам нужно зарегистрировать обработчик pthread_atfork перед разветвлением, который берет блокировку np.random перед разветвлением, а затем освобождает ее после этого? И действительно, я думаю, нам нужно сделать это для каждой блокировки в numpy, что требует чего-то вроде сохранения слабого набора каждого объекта RandomState, и _FFTCache также имеет блокировку...

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

Использование numpy.random.seed не является потокобезопасным. numpy.random.seed изменяет значение семени глобально, в то время как, насколько я понимаю, вы пытаетесь изменить семя локально.

См. документацию.

Если действительно то, чего вы пытаетесь достичь, это заполнение генератора в начале каждого работника, следующее решение:

def worker(n):
    # Removing np.random.seed solves the problem                                                               
    randgen = np.random.RandomState(45678) # RandomState, not seed!
    # ...Do something with randgen...                                           
    return 1234 # trivial return value                                                                         

Делая это полноценным ответом, поскольку он не подходит для комментария.

Немного поиграв, что-то здесь пахнет ошибкой numpy.random. Мне удалось воспроизвести ошибку зависания, и, кроме того, были некоторые другие странные вещи, которые не должны были происходить, например, ручное заполнение генератора не работало.

def rand_seed(rand, i):
    print(i)
    np.random.seed(i)
    print(i)
    print(rand())
def test1():
    with multiprocessing.Pool() as pool:
        [pool.apply_async(rand_seed, (np.random.random_sample, i)).get()
        for i in range(5)]
test1()

имеет вывод

0
0
0.3205032737431185
1
1
0.3205032737431185
2
2
0.3205032737431185
3
3
0.3205032737431185
4
4
0.3205032737431185

С другой стороны, отсутствие передачи np.random.random_sample в качестве аргумента работает просто отлично.

def rand_seed2(i):
    print(i)
    np.random.seed(i)
    print(i)
    print(np.random.random_sample())
def test2():
    with multiprocessing.Pool() as pool:
        [pool.apply_async(rand_seed, (i,)).get()
        for i in range(5)]
test2()

имеет вывод

0
0
0.5488135039273248
1
1
0.417022004702574
2
2
0.43599490214200376
3
3
0.5507979025745755
4
4
0.9670298390136767

Это говорит о том, что за кулисами происходит серьезное дурачество. Хотя не знаю, что еще сказать об этом....

По сути, кажется, что numpy.random.seed изменяет не только переменную «начального состояния», но и саму функцию random_sample.