突然想到，python的线程虽然是native thread，但是由于GIL的存在，并不能利用多处理器优势

[yi huang]

突然想到，python的线程虽然是native thread，但是由于GIL的存在，并不能利用多处理器优势。
不知道是不是这样的，希望达人解释解释。

--
http://codeplayer.blogspot.com/

[limodou]

On 11/1/06, yi huang <yi.cod...@gmail.com> wrote:
> 突然想到，python的线程虽然是native thread，但是由于GIL的存在，并不能利用多处理器优势。
> 不知道是不是这样的，希望达人解释解释。
>

好象是这样的，所以如果要利用多处理器还是使用多进程。

--
I like python!
UliPad <<The Python Editor>>: http://wiki.woodpecker.org.cn/moin/UliPad
My Blog: http://www.donews.net/limodou

[yi huang]

好象是这样的，所以如果要利用多处理器还是使用多进程。

 

那不知道在python中相对微线程来说使用线程还有什么好处？
难怪ruby只实现个微线程。

--
http://codeplayer.blogspot.com/

[limodou]

On 11/1/06, yi huang <yi.cod...@gmail.com> wrote:

> > 好象是这样的，所以如果要利用多处理器还是使用多进程。
> 那不知道在python中相对微线程来说使用线程还有什么好处？
> 难怪ruby只实现个微线程。
>
ruby的问题与python一样。但python目前还解决不了，因为有些模块是c的缘故。使用多线程还是有意义的，因为有些处理不使用多线程就很难处理，象GUI程序，游戏之类的，虽然不是真正的，但是还是可以的。

[yi huang]

ruby的问题与python一样。但python目前还解决不

了，因为有些模块是c的缘故。使用多线程还是有意义的，因为有些处理不使用多线程就很难处理，象GUI程序，游戏之类的，虽然不是真正的，但是还是可以的。

GUI、游戏、网络等正是微线程(StacklessPython)擅长的领域啊，呵呵。
不过 python 里微线程没有普及起来（比如许多GUI框架不支持等），就还不得不使用线程了。
另外 可能还存在某些必须进行阻塞调用的场合 可能就必须使用native线程了，这样的场合有哪些 呢？

--
http://codeplayer.blogspot.com/

[limodou]

On 11/1/06, yi huang <yi.cod...@gmail.com> wrote:

> > ruby的问题与python一样。但python目前还解决不
> >
> 了，因为有些模块是c的缘故。使用多线程还是有意义的，因为有些处理不使用多线程就很难处理，象GUI程序，游戏之类的，虽然不是真正的，但是还是可以的。
>
> GUI、游戏、网络等正是微线程(StacklessPython)擅长的领域啊，呵呵。
> 不过 python 里微线程没有普及起来（比如许多GUI框架不支持等），就还不得不使用线程了。
> 另外 可能还存在某些必须进行阻塞调用的场合 可能就必须使用native线程了，这样的场合有哪些 呢？
>

线程比起协程编程要简单得多，协程麻烦。对于阻塞调用，直接使用python的socket阻塞方式在线程中进行处理好象并没有问题。象UliPad就使用了阻塞线程没有什么问题。具体本地线程的差异没有太深入地了解。现在没有什么感觉。我想差别可能只是性能上的差别。

[yi huang]

线程比起协程编程要简单得多，协程麻烦。对于阻塞调用

，直接使用python的socket阻塞方式在线程中进行处理好象并没有问题。象UliPad就使用了阻塞线程没有什么问题。具体本地线程的差异没有太深入地了解。现在没有什么感觉。我想差别可能只是性能上的差别。

我没说清楚，我说的native线程指的就是python线程，python线程和操作系统的线程应该是一样的（除了多处理器问题）。
我是想讨论下微线程还存在哪些限制。
网络程序只要使用异步代替阻塞的socket调用就可以使用微线程了，而就象 这个例子所展示的那样（尤其是最后那个TestMonkeyPatch函数的内容），这个过程可以相当透明的。
而让GUI框架支持微线程所存在问题好像老大们以前也讨论过 好像还满复杂的，没看得很明白。



--
http://codeplayer.blogspot.com/

[limodou]

On 11/1/06, yi huang <yi.cod...@gmail.com> wrote:

> > 线程比起协程编程要简单得多，协程麻烦。对于阻塞调用
> >
> ，直接使用python的socket阻塞方式在线程中进行处理好象并没有问题。象UliPad就使用了阻塞线程没有什么问题。具体本地线程的差异没有太深入地了解。现在没有什么感觉。我想差别可能只是性能上的差别。
>
> 我没说清楚，我说的native线程指的就是python线程，python线程和操作系统的线程应该是一样的（除了多处理器问题）。

python的线程是不是native线程不好说。

> 我是想讨论下微线程还存在哪些限制。
> 网络程序只要使用异步代替阻塞的socket调用就可以使用微线程了，而就象
> 这个例子所展示的那样（尤其是最后那个TestMonkeyPatch函数的内容），这个过程可以相当透明的。
> 而让GUI框架支持微线程所存在问题好像老大们以前也讨论过 好像还满复杂的，没看得很明白。
>

你所说的微线程是说协程吗？

[yi huang]

你所说的微线程是说协程吗？

恩

--
http://codeplayer.blogspot.com/

[刘鑫]

我来说一下我的经验，在我的使用经验中，混合开发的线程代码中，操作Python虚拟机的是一部分，而大量密集运算或I/O的代码都是纯C++的，我只需要在调用Python API的时候加锁，在调用完毕后及时解锁。可以最大限度的利用资源。如果是协程，整个程序，包括主子过程，无论是C++部分还是Python部分都要等待，效率要低得多。协程可能在某些特定的流程上显得清晰，但它不是真正的并发过程。LUA和Ruby大肆追捧协程，在我看来恐怕和它们还没有实现真正的并发有关。而Python现在有进程/子进程/多解释器线程/单解释器多线程/协程的完整并发体系，你可以选择任何一种适合自己的。
另外，根据Python的文档，即使你加了锁，解释器也不会让锁定的线程一直独占解释器，在执行一定的指令数以后，仍然会挂起并轮询线程集。

2006/11/2, yi huang <yi.cod...@gmail.com>:

你所说的微线程是说协程吗？

恩

--
http://codeplayer.blogspot.com/

--
欢迎访问：
http://blog.csdn.net/ccat

刘鑫
March.Liu

[yi huang]

我来说一下我的经验，在我的使用经验中，混合开发的线程代码中

，操作Python虚拟机的是一部分，而大量密集运算或I/O的代码都是纯C++的，我只需要在调用Python API的时候加锁，在调用完毕后及时解锁。可以最大限度的利用资源。如果是协程，整个程序，包括主子过程，无论是C++部分还是Python部分都要等待，效率要低得多。协程可能在某些特定的流程上显得清晰，但它不是真正的并发过程。LUA和Ruby大肆追捧协程，在我看来恐怕和它们还没有实现真正的并发有关。而Python现在有进程/子进程/多解释器线程/单解释器多线程/协程的完整并发体系，你可以选择任何一种适合自己的。
另外，根据Python的文档，即使你加了锁，解释器也不会让锁定的线程一直独占解释器，在执行一定的指令数以后，仍然会挂起并轮询线程集。

混合开发的话多线程可以利用多处理器优势，线程还是有用的，不过纯python好像就...

另外 stackless 的微线程是可以和python线程一起使用的，不过既然有个GIL，我看不出来这样做有什么好处。

另外你说的 "多解释器线程/单解释器多线程" ，不懂，能否解释解释 ;-)

--
http://codeplayer.blogspot.com/

[Qutr]

你说的对，而且如果你要是调用了其他API在程序执行到API里如果跳不出来的话，其他线程也得不到执行。

 

 

Qutr，qutia...@gmail.com

2006-11-02

[刘鑫]

在多线程的混合式Python程序中，允许建立多个解释器实例，每个解释器的状态是独立的——目前还没有实现完全独立，I/O仍然是共享的。这种模式可以将线程按需要分成不同的解释器组。

2006/11/2, yi huang <yi.cod...@gmail.com>:

[3751]

我最近也在思考这个问题。
Python的GIL不可避免的会带来一些影响。
比如我用C写了两个类A和B。
A有一个方法a用到了B的一个方法b
b为虚函数且ab都没有调用Python API
a方法耗时巨多。在调用它之间如果想充分利用多处理器优势明显a应该释放GIL，但是这样就不可避免的有一个限制：不能使用脚本继承B改写b,再提供给A.a使用。
如果不释放GIL的话，在我们没有改变B.b的能力的时候，调用A的时候就一直在C里面运转没有跑到解释器工作的地方，解释器就没办法把GIL释放挂起并轮询线程集。（也许我理解错了，我这里这样说是假设PyObject_GetAttr，PyObject_CallMethod之类的函数不会跑到解释器那里，我没仔细看到它的代码不太清楚）
两者不可兼得……

[Qutr]

又受教了。

 

 

Qutr，qutia...@gmail.com

2006-11-02

[3751]

在多个解释器下面象pyint这类使用到内存池的对象，不是还共用一个内存池吗？这点我一直很疑惑。这样子多个解释器之间怎么处理？好像多个解释器没有同步吧。

[刘鑫]

我没有读这部分源代码，从文档上来看，应该是独立对象池，多解释器模式本来就是为了分隔线程状态而设计的，使用这种模式的程序一般不会有在子解释器之间传递Python对象需要，如果需要传递什么，就通过C来处理好了。

2006/11/2, 3751 <lwm...@gmail.com>:

在多个解释器下面象pyint这类使用到内存池的对象，不是还共用一个内存池吗？这点我一直很疑惑。这样子多个解释器之间怎么处理？好像多个解释器没有同步吧。