1
mashiro233 2018-05-17 17:31:27 +08:00
不同是正常的,相同是“碰巧”的。理解多进程和多线程的区别就应该懂了。
|
2
BOYPT 2018-05-17 17:42:41 +08:00
因为 linux 下的 multiprocessing 用的是 fork,fork 后的进程跟父进程完全一致,所以 id 号一样; windows 下的实现有所区别。
|
3
wwqgtxx 2018-05-18 00:26:50 +08:00
linux 下用 fork,所以并不改变原来的虚拟地址,而 win 下用的是重启一个新的 python.exe ,所以所有的变量都重新初始化了
|
4
bantao 2018-05-18 11:06:33 +08:00
如上,原因是 2 种系统对多进程的实现有区别。
另外,linux 上列表 g_task 的表现(全局变量地址一样)很容易让人感觉到进程间居然共享内存空间,打印结果表明并不是,实际只是复制了一份地址过去?联想到深拷贝(拷贝后列表 id 不同)、浅拷贝(拷贝后列表中子对象还是同一个,测试发现多进程中也不是)。好奇多进程这里的全局变量 list 是怎么实现的? 最后,官方不建议这么玩,进程间通信、共享数据的方法有很多介绍。 |
5
mashiro233 2018-05-18 13:39:30 +08:00 via Android
@bantao
首先,运行在用户空间的程序所拿到的内存地址,都不是真实的物理内存地址。我们它所在的地址空间叫做 user virtual address space,这些地址是通过内存管理单元( MMU )来对应真实的物理地址。所以当你的程序被系统加载执行后,所获得的指针地址全都是针对你自身的虚拟地址。A 和 B 两个程序的 0x1111 地址,可能指向同一个物理内存地址,也可能指向不同的物理内存地址。同理,A 的 0x1111 和 B 的 0x2222 也可能指向同一个物理内存地址(共享内存)。 所以,这里的 g_task 在 A 和 B 两个不同的 process 观测到指向同一地址,并不能说明什么。可以运行楼主的例子,在 process A中对g_task 进行的修改,并不能在 process B 中观测到。之所以他们内存地址相同,只是因为 Linux 使用 fork 实现让他们"碰巧"相同了而已。 |
6
bantao 2018-05-18 17:15:54 +08:00
@mashiro233 学习了!
补了下 fork 的内容,看看理解的对不对。fork 之后的g_task 在子进程中“某一阶段”是共享的同一真实物理内存,virtual address 是一样的,对应的物理地址也是一样的,但是子进程会有自己独立的新内存空间。由于 Copy-on-Write 机制,只有在子进程发生对 g_task 的修改操作时,才会在子进程独立内存空间为 g_task 重新分配新空间,此时继承自父进程的 virtual address 仍然都不变,但物理地址都变了。 |
7
mashiro233 2018-05-18 18:43:36 +08:00 via Android
@bantao
是的,可以这么理解。 |