[Python-Dev] Python Interpreter Thread Safety? (original) (raw)

Evan Jones ejones at uwaterloo.ca
Sat Jan 29 01:22:52 CET 2005

On Jan 28, 2005, at 18:24, Martin v. Löwis wrote:

5. Many modules may not be thread safe (?). Modules often release the GIL through BEGINALLOWTHREADS, if they know that would be safe if another thread would enter the Python interpreter.

Right, I guess that the modules already have to deal with being reentrant and thread-safe, since Python threads could already cause issues.

Ignoring the issue of #5 for the moment, are there any other areas where this is a problem? I'm curious about how much work it would be to allow concurrent execution of Python code. Define "concurrent". Webster's offers

Sorry, I really meant parallel execution of Python code: Multiple threads simultaneously executing a Python program, potentially on different CPUs.

There have been attempts to implement free threading, and they have failed.

What I was trying to ask with my last email was what are the trouble areas? There are probably many that I am unaware of, due to my unfamiliarity the Python internals.

Due to some unfortunate historical reasons, there is code which enters free() without holding the GIL - and that is what the allocator specifically deals with.

Right, but as said in a previous post, I'm not convinced that the current implementation is completely correct anyway.

Again, the interpreter supports multi-threading today. Removing the GIL is more difficult, though - nearly any container object (list, dictionary, etc) would have to change, plus the reference counting (which would have to grow atomic increment/decrement).

Wouldn't it be up to the programmer to ensure that accesses to shared objects, like containers, are serialized? For example, with Java's collections, there are both synchronized and unsynchronized versions.

Evan Jones

More information about the Python-Dev mailing list