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....@python.org [mailto:python-dev-bounces+kristjan=ccpgames....@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
