[Python-Dev] Python Interpreter Thread Safety?

Donovan Baarda abo at minkirri.apana.org.au
Sat Jan 29 01:44:21 CET 2005


On Sat, 2005-01-29 at 00:24 +0100, "Martin v. Löwis" wrote:
> Evan Jones wrote:
[...]
> The allocator is thread-safe in the presence of the GIL - you are
> supposed to hold the GIL before entering the allocator. 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. Except for this single case, all callers of the allocator
> are required to hold the GIL.

Just curious; is that "one case" a bug that needs fixing, or is the some
reason this case can't be changed to use the GIL? Surely making it
mandatory for all free() calls to hold the GIL is easier than making the
allocator deal with the one case where this isn't done.

I like the GIL :-) so much so I'd like to see it visible at the Python
level. Then you could write your own atomic methods in Python.

BTW, if what Evan is hoping for concurrent threads running on different
processors in a multiprocessor system, then don't :-)

It's been a while since I looked at multiprocessor architectures, but I
believe threading's shared memory paradigm will always be hard to
distribute efficiently over multiple CPU's. If you want to run on
multiple processors, use processes, not threads.

-- 
Donovan Baarda <abo at minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/



More information about the Python-Dev mailing list