Heads up to those who were following, I did my best to clearly outline the situation and direction in the tracker. http://bugs.python.org/issue6132 It includes a patch that will break the expected behavior of the thread lock object but make it possible to test GIL performance. > Note that for the GIL, if you use a CriticalSection object, you should initialize its "spincount" to zero, because the GIL is almost always in contention. That is, if you don't get the GIL right away, you won't for a while. 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. - Phillip
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