np.frombuffer处理multiprocessing.Array后joblib多进程修改未得到预期结果

问题根因 #

• joblib Parallel 默认使用 loky 后端执行多进程任务，该后端通过序列化（pickle）方式传递参数给子进程，传入的numpy数组序列化后，子进程拿到的是独立内存副本，修改不会同步回主进程的共享内存区。
• 对共享内存Array执行np.frombuffer后调用reshape的操作，结合序列化机制会丢失共享内存的地址关联，子进程无法访问原始共享缓冲区。

修复代码 #

推荐在子进程内从共享内存对象构建numpy视图，避免序列化丢失关联，稳定复现预期效果：

from multiprocessing import Array
from ctypes import c_double
import numpy as np
from joblib import Parallel, delayed


def f(shared_arr, arr_len):
    # 子进程内基于共享内存构建numpy视图
    a = np.frombuffer(shared_arr, dtype=c_double)
    a = a.reshape((arr_len, 1))
    for i in range(len(a)):
        a[i] = -a[i]
        print(a[i])


if __name__ == '__main__':
    arr_len = 10
    # 保留原始共享内存对象，不提前覆盖为numpy视图
    shared_arr = Array(c_double, range(arr_len), lock=False)
    # 主进程自用的numpy视图
    arr = np.frombuffer(shared_arr, dtype=c_double)
    arr = arr.reshape((arr_len, 1))

    # 指定multiprocessing后端，传递共享内存对象
    Parallel(n_jobs=2, backend='multiprocessing')(delayed(f)(shared_arr, arr_len) for j in range(1))

    print(arr[:])

补充说明 #

• 原有代码的快速修复方式仅需给Parallel添加参数backend='multiprocessing'即可输出预期结果，但直接传递numpy共享视图的写法稳定性较差，不推荐生产环境使用。
• 多进程同时修改共享内存的场景下，建议开启Array的锁机制避免读写冲突，单进程修改场景可保留lock=False提升性能。

内容的提问来源于stack exchange，提问作者lazy