[Python-ideas] Ideas towards GIL removal (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Sat Apr 14 02:51:04 CEST 2007

Brett Cannon wrote:

In reality this is true, but obviously not technically true. You could delete a class if you really wanted to. But obviously it rarely happens.

And if it does, the worst that will happen is that the original version will hang around, tying up a small amount of memory.

I wonder what the overhead is going to be. If for every INCREF or DECREF you have to check that an object is immortal or whether it is a thread-owned object is going to incur at least an 'if' check, if not more.

Clearly, there will be a small increase in overhead. But it may be worth it if it avoids the need for a rather expensive lock/unlock. It was pointed out earlier that, even using the special instructions provided by some processors, this can take a great many times longer than a normal memory access or two.

And for the second idea, adding two more fields to every object might be considered expensive by some in terms of memory.

Again, it's a tradeoff. If it enables removal of the GIL and massive threading on upcoming multi- core CPUs, it might be considered worth the cost.

Also, how would this scenario be handled: object foo is created in thread A ... is passed to thread B, and then DECREF'ed in thread B as the object is no longer needed by anyone.

I'll have to think about that. If a thread gives away a reference to another thread, it really needs to be a global reference rather than a local one. The tricky part is telling when this happens.

But if objects start with a global refcount of 1 but a local refcount of 0 and it is DECREF'ed locally then wouldn't that fail for the same reason?

That one's easier -- if the local refcount is 0 on a decref, you need to lock the object and decrement the global refcount.

-- Greg

More information about the Python-ideas mailing list