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

[Phillip Sitbon]

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.

- Phillip

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