global interpreter lock not working as it should

[Jonathan Hogg]

On 30/7/2002 22:49, in article
mailman.1028065844.28617.python-list at python.org, "anton wilson"
<anton.wilson at camotion.com> wrote:

> It would seem that python developers like to assume other people are calling
> them stupid and lazy and take hints as offensive or demanding action. I've
> never seen so much hostility to a bug in my life.

A "hint"? You have to be joking. The very subject line of this thread
indicates that you believe you understand better how the GIL "should" work.

Everyone else has said this already, but let me make it very plain:

THIS IS NOT A BUG

As explained, the context switching of threads is decided by the native
thread implementation. Your threading system is choosing not to switch every
time the GIL is released. This is a very sensible thing to do as no matter
how lightweight threads are, switching them requires non-zero time.

If nothing is waiting on I/O then the thread implementation might as well
let the first CPU-bound thread run riot. If you have two CPU-bound threads
that you want to run, and they don't communicate with each other, then
running them with large timeslices *guarantees the maximum possible
throughput*.

The larger the timeslice, the more efficient the system is. The ideal
situation is to run one fully to completion and then run the other fully to
completion as this involves precisely one context switch which is O(1). If
it switched every 10 instructions then the context switch cost would be
O(n).

Unless you have a multiple CPU machine you are wasting your time. If you do
have a multiple CPU machine, then you will have to extract the CPU-intensive
work out to a C extension which can operate with the GIL released. [And make
sure you're using kernel-level threads as user-level threads can't utilise
multiple CPUs anyway.]

Jonathan