[Python-Dev] Making the GIL faster & lighter on Windows (original) (raw)

Phillip Sitbon phillip.sitbon+python-dev at gmail.com
Thu May 28 18:11:17 CEST 2009

The testing patch I submitted to the tracker includes a semaphore as well, and I did take some time to try it out. It seems that it's no better than the event object, either for a single thread or scaled to many threads... so this does appear to indicate that the WaitForXX functions are costly (which is expected) and scale terribly (which is unfortunate). I had always believed event objects to be "slower" but I'm not seeing a difference here compared to semaphores. My guess is that these results could be very different if I were to test on, say, Windows 2000 instead of Vista.

2009/5/28 Kristján Valur Jónsson <kristjan at ccpgames.com>:

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.

More information about the Python-Dev mailing list