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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4