[Python-Dev] Making the GIL faster & lighter on Windows

[Kristján Valur Jónsson]

I've often thought of this.
The problem is that the GIL uses the regular python "lock" which has to be non-recursive, since it is used for synchronization operations other than mutual exclusion, e.g. one thread going to sleep, and another waking it up.
Now, we could easily create another class of locks, a python "mutex"  or a "critical section" even, which is allowed (but not required) to be recursive.  On other platforms, this could fall back to being the good old lock.  Requiring it to be recursive would mean that we would need implementations for all platforms.  Which is possible, I suppose, building on the old python lock...

For the GIL, we would then use a python "mutex" or "critical section" whichever you prefer.

Note that for the GIL, if you use a CriticalSection object, you should initialize its "spincount" to zero, because the GIL is almost always in contention.  That is, if you don't get the GIL right away, you won't for a while.
I don't know what kernel primitive the Critical Section  uses, but if it uses an Event object or something similar, we are in the same soup, so to say, because the CriticalSection's spinlocking feature buys us nothing.

K

-----Original Message-----
From: python-dev-bounces+kristjan=ccpgames.com at python.org [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf Of Phillip Sitbon
Sent: 26. maí 2009 19:49
To: python-dev at python.org
Subject: [Python-Dev] Making the GIL faster & lighter on Windows

Hi everyone,

I'm new to the list but I've been embedding Python and working very
closely with the core sources for many years now. I discovered Python
a long time ago when I needed to embed a scripting language and found
the PHP sources... unreadable ;)

Anyway, I'd like to ask something that may have been asked already, so
I apologize if this has been covered.

Instead of removing the GIL, has anyone thought of making it more
lightweight? The current situation for Windows is that the
single-thread case is decently fast (via interlocked operations), but
it drops to using an event object in the case of contention. (see
thread_nt.h)