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

[Kristján Valur Jónsson]

You are right, a small experiment confirmed that it is set to 0 (see SetCriticalSectionSpinCount())
I had assumed that a small non-zero value might be chosen on multiprocessor machines.

Do you think that the problem lies with the use of the "event" object as such?  Have you tried using a "semaphore" or "mutex" instead?  Or do you think that all of the synchronizations primitives that rely on the WaitForMultipleObjects() api are subject to the same issue?

Cheers,

Kristján

-----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: 27. maí 2009 22:23
To: python-dev
Subject: Re: [Python-Dev] Making the GIL faster & lighter on Windows


If I'm not mistaken, calling InitializeCriticalSection rather than
InitializeCriticalSectionAndSpinCount (gotta love those long function
names) sets the spin count to zero. I could tell when the spin count
wasn't zero as far as performance is concerned - spinning is too much
of a gamble in most contention situations.

> 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.

Judging from the increase in speed and CPU utilization I've seen, I
don't believe this is the case. My guess is that it's something
similar to a futex.