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

[Phillip Sitbon]

> You should definitely open a bug entry in http://bugs.python.org. There, post
> your patch, some explanations and preferably a quick way (e.g. a simple script)
>  of reproducing the speedups (without having to install a third-party library or
> extension, that is).

I'll get started on that. I'm assuming I should generate a patch from
the trunk (2.7)? The file doesn't look different, but I want to make
sure I get it from the right place.

> I wonder if the patch could be structured as a conditional compilation?  You
> know how many different spots are touched, and how many lines per spot.
>
> If it could be, then theoretically it could be released and people could  do
> lots of comparative stress testing with different workloads.

That would be easy to do, because I am just replacing the
*NonRecursiveMutex functions.

> What about fairness? I don't know off-hand whether the GIL is
> fair, or whether critical sections are fair, but it needs to be
> considered.

If you define fairness in this context as not starving other threads
while consuming resources, that is built into the interpreter via
sys.setcheckinterval() and also anywhere the GIL is released for I/O.
What might be interesting is to see if releasing a critical section
and immediately re-acquiring it every _Py_CheckInterval bytecode
operations behaves in a similar manner (see ceval.c, line 869). My
best guess right now is that it will behave as expected when not using
the spin-based critical section. AFAIK, the kernel processes waiters
in a FIFO manner without regard to priority. Because a guarantee of
mutual exclusion is absolutely necessary, it's up to applications to
provide fairness. Python does a decent job of this.

- Phillip