[Python-Dev] Removing the GIL (Me, not you!)

[Tennessee Leeuwenburg]

Pardon me for talking with no experience in such matters, but...

Okay, incrementing a reference counter is atomic, therefore the cheapest
possible operation. Is it possible to keep reference counting atomic in a
multi-thread model?

Could you do the following... let's consider two threads, "A" and "B". Each
time an object is created, a reference count is created in both "A" and "B".
Let's suppose "A" has a real reference and "B" has no reference really.
Couldn't the GC check two reference registers for a reference count? The
object would then be cleaned up only if both registers were 0.

To exploit multiple CPUs, you could have two persistent Python processes on
each CPU with its own mini-GIL. Object creation would then involve a call to
each process to create the reference and GC would involve checking each
process to see what their count is. However, it would mean that within each
process, threads could create additional references or remove references in
an atomic way.

In a single-CPU system, this would be the same cost as currently, since I
think that situation would devolve to having just one place to check for
references. This seems to mean that it is the case that it would be no more
expensive for a single-CPU system.

In a two-CPU system, I'm no expertise on the actual call overheads of object
creation and garbage collection, but logically it would double the effort of
object creation and destruction (all such operations now need to occur on
both processes) but would keep reference increments and decrements atomic.

Once again, I'm really sorry if I'm completely off-base since I have never
done any actual coding in this area, but I thought I'd make the suggestion
just in case it happened to have relevance.

Thanks,
-Tennessee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070914/e11d56bb/attachment.htm