import multiprocessing as mpdef delay_one_second(event):print in SECONDARY process, preparing to wait for 1 secondevent.wait(1)print in the SECONDARY process, preparing to raise the eventevent.set...

import multiprocessing as mp
def delay_one_second(event):
print 'in SECONDARY process, preparing to wait for 1 second'
event.wait(1)
print 'in the SECONDARY process, preparing to raise the event'
event.set()
if __name__=='__main__':
evt = mp.Event()
print 'preparing to wait 10 seconds in the PRIMARY process'
mp.Process(target = delay_one_second, args=(evt,)).start()
evt.wait(10)
print 'PRIMARY process, waking up'
这段代码(使用cmd.exe中的“ python module.py”命令从模块内部很好地运行)产生了令人惊讶的结果.
主要过程显然只在唤醒之前等待1秒钟.为此,这意味着辅助过程在主过程中具有对对象的引用.
怎么会这样?我曾期望必须使用multiprocessing.Manager()在进程之间共享对象,但是这怎么可能呢?
我的意思是进程不是线程,它们不应该使用相同的内存空间.任何人都知道这里发生了什么吗?
解决方法:
简短的答案是共享内存不是由单独的进程管理的.它由操作系统本身管理.
如果您花一些时间浏览多处理源,则可以看到它是如何工作的.您将看到一个Event对象使用一个Semaphore和一个Condition,它们都依赖于SemLock对象提供的锁定行为.反过来,这包装了_multiprocessing.SemLock对象,该对象在c中实现,并且取决于sem_open(POSIX)或CreateSemaphore(Windows).
这些是c函数,可以访问由操作系统本身(在本例中为信号灯)管理的共享资源.它们可以在线程或进程之间共享;操作系统负责一切.发生的情况是,在创建新的信号量时,将为其指定一个句柄.然后,在创建需要访问该信号量的新进程时,将为其提供一个句柄的副本.然后,它将该句柄传递给sem_open或CreateSemapohre,并且操作系统为新进程提供对原始信号量的访问权限.
因此,内存是共享的,但作为操作系统对同步原语的内置支持的一部分而被共享.换句话说,在这种情况下,您无需打开新进程即可管理共享内存.操作系统接管该任务.但这仅是可行的,因为Event不需要比信号量更复杂的东西来工作.
本文标题为:Python multiprocessing.Process对象的行为类似于在另一个进程中保存对对象的引用.为什么?


基础教程推荐
- Python实现图片和视频的相互转换 2023-08-08
- python-正则表达式用于解析诸如字符串之类的shell命令 2023-11-13
- 如何在Windows中的python中创建服务? 2023-11-10
- python-pycurl失败,但是curl(来自bash)在ubuntu中工作 2023-11-10
- 在Fedora Linux上的Jupyter中运行Python 2和3 2023-11-14
- windows下python环境安装 2023-09-04
- python-yml文件读写与xml文件读写 2022-08-30
- Python平均数 2023-10-08
- python-在dask生成的进程中调用dask 2023-11-11
- CentOS7下部署Python3+Django+uwsgi+Nginx 2023-09-03