gpt4 book ai didi

python - 通过多进程生成的对象标识

转载 作者:行者123 更新时间:2023-12-05 04:29:02 25 4
gpt4 key购买 nike

我一直在试验 python 中的多处理模块,我想知道如何通过生成的进程处理不同并行化方法的参数。这是我使用的代码:

import os
import time
import multiprocessing


class StateClass:
def __init__(self):
self.state = 0

def __call__(self):
return f"I am {id(self)}: {self.state}"


CONTEXT = multiprocessing.get_context("fork")

nb_workers = 2

stato = StateClass()


def wrapped_work_function(a1, a2, sss, qqq):
time.sleep(a1 + 1)
if a1 == 0:
sss.state = 0
else:
sss.state = 123
for eee in a2:
time.sleep(a1 + 1)
sss.state += eee
print(
f"Worker {a1} in process {os.getpid()} (parent process {os.getppid()}): {eee}, {sss()}"
)
return sss


print("main", id(stato), stato)

manager = CONTEXT.Manager()
master_workers_queue = manager.Queue()

work_args_list = [
(
worker_index,
[iii for iii in range(4)],
stato,
master_workers_queue,
)
for worker_index in range(nb_workers)
]

pool = CONTEXT.Pool(nb_workers)
result = pool.starmap_async(wrapped_work_function, work_args_list)

pool.close()
pool.join()
print("Finish")
bullo = result.get(timeout=100)
bullo.append(stato)
for sss in bullo:
print(sss, id(sss), sss.state)

例如,我从中得到以下输出:

main 140349939506416 <__main__.StateClass object at 0x7fa5c449dcf0>
Worker 0 in process 9075 (parent process 9047): 0, I am 140350069832528: 0
Worker 0 in process 9075 (parent process 9047): 1, I am 140350069832528: 1
Worker 1 in process 9077 (parent process 9047): 0, I am 140350069832528: 123
Worker 0 in process 9075 (parent process 9047): 2, I am 140350069832528: 3
Worker 0 in process 9075 (parent process 9047): 3, I am 140350069832528: 6
Worker 1 in process 9077 (parent process 9047): 1, I am 140350069832528: 124
Worker 1 in process 9077 (parent process 9047): 2, I am 140350069832528: 126
Worker 1 in process 9077 (parent process 9047): 3, I am 140350069832528: 129
Finish
<__main__.StateClass object at 0x7fa5c43ac190> 140349938516368 6
<__main__.StateClass object at 0x7fa5c43ac4c0> 140349938517184 129
<__main__.StateClass object at 0x7fa5c449dcf0> 140349939506416 0

初始类实例 stato 的 ID 140349939506416,并且如我所料在其整个生命周期中保持不变。在 starmap_async 方法中,我确实得到了同一类的两个不同实例(每个工作人员/进程一个),我可以修改它们并保留它们的 state 属性直到结束的脚本。无论如何,这些实例的 id 最初是相同的 (140350069832528),并且在脚本的末尾,它们都有另一个 id,这也与原始实例的 id 不同。具有相同的 id 并不意味着它们在内存中具有相同的地址?那么他们怎么可能保持不同的状态呢?此行为与 fork 上下文有关吗?

最佳答案

首先,当我运行这个(Debian Linux,Python 3.9.7)时,我没有发现 sss 实例的 id 对于两个子进程是相同的:

main 140614771273680 <__main__.StateClass object at 0x7fe36d7defd0>
Worker 0 in process 19 (parent process 13): 0, I am 140614770671776: 0
Worker 0 in process 19 (parent process 13): 1, I am 140614770671776: 1
Worker 1 in process 20 (parent process 13): 0, I am 140614761373648: 123
Worker 0 in process 19 (parent process 13): 2, I am 140614770671776: 3
Worker 0 in process 19 (parent process 13): 3, I am 140614770671776: 6
Worker 1 in process 20 (parent process 13): 1, I am 140614761373648: 124
Worker 1 in process 20 (parent process 13): 2, I am 140614761373648: 126
Worker 1 in process 20 (parent process 13): 3, I am 140614761373648: 129
Finish
<__main__.StateClass object at 0x7fe36ce7b7f0> 140614761428976 6
<__main__.StateClass object at 0x7fe36ce7b520> 140614761428256 129
<__main__.StateClass object at 0x7fe36d7defd0> 140614771273680 0

即使您正在 fork 新进程,work_args_list 列表中的 stato 实例也会作为 sss 传递给您的辅助函数。传递给在不同进程/地址空间中运行的池工作函数的参数由 pickle 完成,它序列化然后反序列化实例,从而制作一个副本,将 general 在反序列化时有不同的 id。在这种特殊情况下,每个进程在使用 fork 方法时都继承全局变量 stato 并且它在所有进程/地址空间中应该具有相同的 id 。如果我们修改 wrapped_work_function 打印出 stato 的 id,我们可以验证这一点:

def wrapped_work_function(a1, a2, sss, qqq):
print('The id of the inherited stato is', id(stato))
time.sleep(a1 + 1)
if a1 == 0:
sss.state = 0
else:
sss.state = 123
for eee in a2:
time.sleep(a1 + 1)
sss.state += eee
print(
f"Worker {a1} in process {os.getpid()} (parent process {os.getppid()}): {eee}, {sss()}"
)
return sss

那么打印出来的是:

main 140456701534160 <__main__.StateClass object at 0x7fbe9fcd1fd0>
The id of the inherited stato is 140456701534160
The id of the inherited stato is 140456701534160
Worker 0 in process 43 (parent process 37): 0, I am 140456700920112: 0
Worker 0 in process 43 (parent process 37): 1, I am 140456700920112: 1
Worker 1 in process 44 (parent process 37): 0, I am 140456700920112: 123
Worker 0 in process 43 (parent process 37): 2, I am 140456700920112: 3
Worker 0 in process 43 (parent process 37): 3, I am 140456700920112: 6
Worker 1 in process 44 (parent process 37): 1, I am 140456700920112: 124
Worker 1 in process 44 (parent process 37): 2, I am 140456700920112: 126
Worker 1 in process 44 (parent process 37): 3, I am 140456700920112: 129
Finish
<__main__.StateClass object at 0x7fbe9f36e880> 140456691689600 6
<__main__.StateClass object at 0x7fbe9f36eb20> 140456691690272 129
<__main__.StateClass object at 0x7fbe9fcd1fd0> 140456701534160 0

所有地址空间都看到相同的 stato id,即 140456701534160。如果每个地址空间看到相同的继承 stato id,则 sss 的 id ,它应该是 stato 的单独副本, 不能与 stato 具有相同的 ID。当我运行代码时,它们的 ID 与我预期的不同。但是在不同地址空间中运行的每个 sss 可能具有彼此相同的 id,但这并不能保证(在第二次运行时它们是相同的)。

但即使 sss 实例具有相同的 id 和相同的地址,这两个实例存在于两个不同的进程中,因此是两个不同的地址空间。这就是它们可以保持不同状态的原因。顺便说一句,当您的辅助函数返回 sss 时,它会使用 pickle 传递回主进程,它序列化和反序列化实例,因此实际上制作了原始副本。这就是您看到返回的 ID 不同的原因。

另外:您有 bullo = result.get(timeout=100) 测试可能的超时。但此语句之前调用了 pool.close()pool.join()。这两个调用将等待所有提交的任务完成。因此,当您调用 result.get 时,任务保证已完成并且永远不会导致超时异常。

关于python - 通过多进程生成的对象标识,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/72445734/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com