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

"Martin v. Löwis" martin at v.loewis.de
Thu Sep 13 17:55:24 CEST 2007

"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

More information about the Python-Dev mailing list