- 主题:各位大神：python能做到GIL锁真正去掉像C++一样支持多线程吗？
小白请教一下
--
FROM 221.221.144.*
【 在 aiworking 的大作中提到: 】
: 小白请教一下
:
这个很难， python内核引擎可以， 但是， python程序开发一般要涉及大量的官方库和第三方库。
很多库，名义上的多线程（各种伪多线程库， 都是名义上的， 实际没有CPU多线程竞争，GIL锁已经把他们序列化到一个CPU上执行了，导致这种所谓多线程不用锁或者乱用锁也不会发现问题，GIL锁一去掉就暴露了），
因此，需要等到这些库也去掉GIL锁， 并完成大量的测试， 稳定以后才行。
--
FROM 115.171.244.*
做不到，因为所有的第三方模块都假定存在 GIL，它们自己缺少必要的加锁。
去掉 GIL 之后，很多第三方模块都会跑飞掉。
Python 本身提供了好几种解决方案: multiprocessing 用于计算密集的，threading 用于 IO 密集的，以后还会提供子解释器，这个应该是最佳方案。
【 在 aiworking 的大作中提到: 】
: 小白请教一下
--
FROM 110.84.121.*
如果所有模块都是：
1 纯python
2 RPC/IPC
就好了
【 在 hgoldfish 的大作中提到: 】
: 做不到，因为所有的第三方模块都假定存在 GIL，它们自己缺少必要的加锁。
: 去掉 GIL 之后，很多第三方模块都会跑飞掉。
: Python 本身提供了好几种解决方案: multiprocessing 用于计算密集的，threading 用于 IO 密集的，以后还会提供子解释器，这个应该是最佳方案。
: ...................
--
FROM 139.227.19.*
Python 是胶水语言，不可能做到所有模块纯 Python 的啊。
其实你需要的语言是 Java 哈哈。
Java 现在已经可以直接执行 .java 文件了。如果能再进一步，改成 Python 这种执行模式，那就是你想要的语言的了。
【 在 JulyClyde 的大作中提到: 】
: 如果所有模块都是：
: 1 纯python
: 2 RPC/IPC
: ...................
--
修改:hgoldfish FROM 110.84.121.*
FROM 110.84.121.*
【 在 hgoldfish 的大作中提到: 】
: 做不到，因为所有的第三方模块都假定存在 GIL，它们自己缺少必要的加锁。
: 去掉 GIL 之后，很多第三方模块都会跑飞掉。
: Python 本身提供了好几种解决方案: multiprocessing 用于计算密集的，threading 用于 IO 密集的，以后还会提供子解释器，这个应该是最佳方案。
: ...................
>Python 本身提供了好几种解决方案: multiprocessing 用于计算密集的，threading 用于 IO 密集的，
>以后还会提供子解释器，这个应该是最佳方案。
我说的就是这这些类， 它们只是多线程的外形， 因为GIL的存在， 运行时都不可能产生真正多线程时的竞合条件。
因此， 使用这些库的各种衍生产品库， 即使有多线程误用， 在以前GIL保证的情况下，
也根本不会出BUG， 但是， 一旦把GIL锁去掉， 跑成真正多线程， 这些衍生库都需要追加额外的
多线程测试，以确保在多线程竞合条件下， 仍然是工作正常。
估计从GIL在内核支持， 到这些库都完成功能测试，bug修复，版本迭代估计要等一等了。
--
FROM 115.171.244.*
multiprocessing 多进程时是可以跳过 GIL 的，都在不同的进程了。没问题的。
而子解释器底层是多线程，所以交换数据特别快。又每个线程都拥有自己的 GIL，所以仍然兼容以前的第三方模块，或者只需要少量改动。这个方案应该是最佳的。Python 目前已经完成了每个线程都拥有自己的 GIL 这个改造。创建多个子解释器的 API 也已经有了。现在还缺的是实现子解释器之间的极速对象传递。离最终完成已经不远了。
对比一下，go, java 都把协程和线程混合所以带来几个大的缺点：
1. 协程之间的通信仍然需要加锁。把协程的开销搞得很大，也容易出错。
2. 因为协程在线程间跳来跳去。所以用协程搞不了 GUI 开发。
3. 协程的实现特别复杂。需要对整个语言和周边的第三方模块进行全面的改造。
在 go, java 之外的其它语言就很烂了，像 c#, js 不客气地说就是一坨垃圾。现在的 Python 也是垃圾。不止使用会传染的 async/await 还在语言里面混入线程这种操作系统的概念，让程序员多了很多心智负担。
我认为安胖子是历史的罪人！全世界最烂的程序员！
唯一正确的答案就是 Python 的这个子解释器。如果 Python 能够快点出来，那么又一次走在世界的前面。期待 Python 废除 async/await，改回 gevent，再加个子解释器，无敌！
【 在 poggy 的大作中提到: 】
: >Python 本身提供了好几种解决方案: multiprocessing 用于计算密集的，threading 用于 IO 密集的，
: >以后还会提供子解释器，这个应该是最佳方案。
: 我说的就是这这些类， 它们只是多线程的外形， 因为GIL的存在， 运行时都不可能产生真正多线程时的竞合条件。
: ...................
--
修改:hgoldfish FROM 110.84.121.*
FROM 110.84.121.*
c#已经实时eval了，在安卓4发行之前，基于c#的asp.net和winform wpf 几乎牢牢占据软件开发头号编程语言，竟然说c#是垃圾？
【 在 hgoldfish 的大作中提到: 】
: multiprocessing 多进程时是可以跳过 GIL 的，都在不同的进程了。没问题的 ...
--
FROM 113.83.248.*
3.13已经可以了，不过是experimental
【 在 aiworking 的大作中提到: 】
: 小白请教一下
:
--
FROM 58.247.23.*
【 在 hgoldfish 的大作中提到: 】
: multiprocessing 多进程时是可以跳过 GIL 的，都在不同的进程了。没问题的。
: 而子解释器底层是多线程，所以交换数据特别快。又每个线程都拥有自己的 GIL，所以仍然兼容以前的第三方模块，或者只需要少量改动。这个方案应该是最佳的。Python 目前已经完成了每个线程都拥有自己的 GIL 这个改造。创建多个子解释器的 API 也已经有了。现在还缺的是实现子解释器之间的极速对象传递。离最终完成已经不远了。
: 对比一下，go, java 都把协程和线程混合所以带来几个大的缺点：
: ...................
嗯， 多进程， 都在不同进程了， GIL自然不共享。
不过， 多线程， 实际上， multithread的多个实例， 都跑在同一个解释器下， 其实也都跑在同一个线程下面， 因此， 也就没有了多线程竞合。当然也有调度产生的执行序列被分片。但是， 线程锁已经不是实际意义的线程锁，因为都在一个线程里。
--
FROM 124.126.3.*