[Python-Dev] Python Interpreter Thread Safety?

[Evan Jones]

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 BEGIN_ALLOW_THREADS, 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