global interpreter lock not working as it should

[Jonathan Hogg]

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

> What's the purpose of releasing an reaquiring the lock if no other threads
> can run? It's easy to say that one can't assume about the order of running on
> different platforms as a scapegoat, but the main problem is that the GIL is
> NOT implemented properly with pthreads. So nearly every system that uses
> pthreads will show this kind of queue behaviour. I have a feeling that there
> is a hidden race condition between when the thread wakes up the other thread
> and tries to reaquire the lock. It really should be fixed, or else what's the
> point of threads? Threads are for concurrency!

I think the main problem is that you're trying to do something with Python
threads that they just weren't designed for: CPU intensive work.

Even if you "fix" Python to force a re-schedule, the GIL means you still
only have one thread executing at a time and get NO CONCURRENCY.

If you have a multiple-CPU machine and a kernel-level thread implementation
and a multi-threaded CPU-intensive application, then the only way you're
going to get true concurrency is to do the hard work in a C extension with
the GIL released.

Python threads just aren't any good for parallelism. They're mainly useful
as a communication abstraction.

You can browse the archives of this group for many (many) discussions on
"fixing" the GIL, but you aren't going to get a solution.

[and certainly not by assuming the Python developers are too lazy or stupid
to have thought of this before and demanding some kind of action.]

-no-after-you-ly y'rs,

Jonathan