[Python-ideas] Ideas towards GIL removal
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
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
> 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
> 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.
More information about the Python-ideas