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

["Martin v. Löwis"]

>> "Since we are guaranteeing that synchronized code is running on a single
>> core, it is the equivalent of a lock at the cost of a context switch."
>>
>> This is precisely what a lock costs today: a context switch.
>>
> 
> Really? Wouldn't we save some memory allocation overhead (since in my
> design, the "lock" is a really just simple kernel instruction as opposed
> to a full blown object)

The GIL is a single variable, not larger than 50 Bytes or so. Locking
it requires no memory at all in user-space, and might require 8 bytes
or so per waiting thread in kernel-space.

> thereby lowering lock overhead

Why do you think "lock overhead" is related to memory consumption?

> Since we're using an asynch message queue for the synch-server, it
> sounds like a standard lock-free algorithm.

You lost me here. What are you trying to achieve? It's not the lock
that people complain about, but that Python runs serially most
of the time.

> I think I neglected to mention that the locking would still need to be
> more fine grained - perhaps only do the context switch around refcounts
> (and the other places where the GIL is critical).

I think this is the point where I need to say "good luck implementing
it".

> Well, my interpretation of the current problem is that removing the GIL
> has not been productive because of problems with lock contention on
> multi-core machines.

My guess is that this interpretation is wrong. It was reported that
there was a slowdown by a factor of 2 in a single-threaded application.
That can't be due to lock contention.

> If we can somehow guarantee all GC operations (which is why the GIL is
> needed in the first place)

No, unless we disagree on what a "GC operation" is.

Regards,
Martin