[Python-ideas] Ideas towards GIL removal
greg.ewing at canterbury.ac.nz
Sat Apr 14 03:26:14 CEST 2007
> I'm thinking along similar lines, but my approach is to eliminate
> refcounting entirely.
That's a possibility, although refcounting does have
some nice properties -- it's cache-friendly, and it's
usually fairly easy to get it to work with other
libraries that have their own scheme for managing
memory and don't know about Python's one.
> For example, take the case of a dictionary in which more than one thread
> is inserting values. .. I
> think we want to avoid the Java situation where every object has its own
Having to lock dictionaries mightn't be so bad, as
long as it can be done using special instructions.
It's still a much larger-grained locking unit than
an incref or decref.
But I'm wondering whether the problem might get
solved for us from the hardware end if we wait
long enough. If we start seeing massively-multicore
CPUs, I expect there will be a lot of pressure to
come up with more efficient ways of doing fine-
grained locking in order to make effective use
of them. Maybe a special lump of high-speed
multi-port memory used just for locks, with
surrounding hardware designed for using it as
More information about the Python-ideas