Question about Python threads

brueckd at tbye.com brueckd at tbye.com
Wed Aug 28 16:47:46 CEST 2002


On 28 Aug 2002, Ville Vainio wrote:

> brueckd at tbye.com wrote in message news:<mailman.1030372004.29144.python-list at python.org>...
> 
> > > Yes, Java uses garbage collection. On a related note: could GIL be
> > > dumped if refcounts were no longer used (ie Python changed over to gc
> > > instead)?
>  
> > Well, refcounts _are_ a method of gc, but either way the answer is still
> > 'no'. ;-)
> 
> GC is often thought of as an alternative to refcounting - obviously
> it's another method of automatic resource deallocation, but they are
> often thought of as seperate things.

This is not the common definition of garbage collection. GC is a general
term for _any_ algorithm that automatically determines what memory is no
longer in use and can be reclaimed. See the book "Garbage Collection:
Algorithms for Automatic Dynamic Memory Management" for example. Reference
counting is most definitely one form of GC, and mark-and-sweep is another.  
I don't think mark-and-sweep is required by the Java spec, but I do
believe it is (or at least was) the method used in most Java VM
implementations.

> > The two issues are pretty much unrelated: the GIL ensures that
> 
> My point was that reference counting is something that obviously
> requires locking, while other uses of GIL might be less compulsory.

Right, and I'm saying that, to my knowledge, in the current implementation
those other uses are _not_ less compulsory. As implemented the interpreter
is not threadsafe so reference counting is just one of many things that
would have to be reworked in order to remove the GIL. Could Python be
implemented without a GIL? Of course! Is it? No.

> > Refcounting/other GC methods apply to single- _and_ multi-threaded
> > programs, and their benefit comes when it's time for objects to "die" - 
> > knowing what is safe to destroy and when to do it.
> 
> You missed the point: refcounting is not a problem in single threaded
> programs, but in multithreaded programs it requires locking, in order
> for objects to always have a legal rc value.

Right, but you missed _my_ point. ;-) And that is that with _any_ form of 
garbage collection thread safety is still an issue. The two aren't tied 
together: with the GIL you could still choose other forms of GC, e.g. 
mark-and-sweep, and choosing another form of GC would not eliminate the 
need for the GIL or some other thread safety mechanism.

-Dave





More information about the Python-list mailing list