Thread State and the Global Interpreter Lock

[Michael Chermside]

Afanasiy writes:
> Are there plans to make the Python interpreter 
> "fully thread safe" in a future version?
> 
> http://www.python.org/doc/current/api/threads.html

No, the Global Interpreter Lock will not be going away in
any forseeable version of Python. (Well, of cPython anyhow.)
But the document you referred to is somewhat misleading.
It is written from the point of view of Guido or others
who are writing Python itself (the interpreter). The code
that these people write is not "fully thread safe", and
because of that, the Global Interpreter Lock must exist.

But if you are writing programs IN Python, they they ARE
fully thread safe. You can launch threads and do whatever
you like in them. The only issue is that because of the
Global Interpreter Lock, only one thread will be executing
new Python bytecodes at a time. If you have only one CPU,
then that is no restriction at all... after all, ALL
multithreading must be done by taking turns. If most of
your threads are blocked waiting for things like file or
socket IO (a very common use for threads) then that's no
problem... the threads that are waiting won't hold up any
others. And if your threads are busy calling out to some
lengthy computation written in C (the best place for a CPU 
intensive calculation), then _IF_ the author of the C
extension used the Global Interpreter Lock (GIL for short)
properly, it won't hold up your program. And if you DO
happen to have a multi-processor machine, aren't running
anything else but this Python program, and are doing
lengthy computations (written in Python) in multiple
threads, well then only one of your CPUs will be working
at a time.

It's a wart (if only a small, special case one), and I'm
sure that the Python maintainers would love to fix it.
But they've considered it and decided that it would require
some VERY deep changes in cPython... rewriting the very
core of it. So they're not planning to do it. (Although
the new version coming out very soon now has some
improvements to make it easier for C programmers to make
their extensions cooperate like they ought to.)

If you'd like to, there are a few options. I think that
the best option is to simply try it and see... in all
likelihood you'll find that Python is "fast enough" as it
is, and if not, there are lots of other ways to achieve
large speedups. Threading behavior is NOT likely to be
the biggest contributor. But if you're doing specialty
work and already know that your compute threads must make
simultaneous use of multiple CPUs, then you have a couple
of alternatives. Jython, the java-based implementation of
Python does not have this restriction (assuming that the
JVM you use doesn't have a similar limitation), although
it's usually slower than cPython. Or you could take a
look at the source to Python and see if you can figure
out a clever solution that others have missed. If you DID
contribute a "fix", I'm sure it would be gleefully 
accepted (after being vigorously tested).

-- Michael Chermside