Kristján Valur Jónsson wrote:
I think you may be missing the point. If the GIL is implemented in a naive way on a platform, then releasing the gil and reclaiming it (such as is done during a checkinterval) can cause the same thread to get it again. Thus, the idea that this checkinterval should allow another thread waiting for the gil to run, would not work. Apparently, "fairness" of some locking primitives is being given up for efficiency reasons in some operatins systems, like Vista. I tested this by implementing a GIL like mechanism on a multicore maching using windows CriticalSections and Mutexes, both of which would starve the other threads. Semaphores work, though and the python locks on windows (using an atomic counter and an Event object) also work.
So, alghough Sturla's claim isn't valid for windows, there might be systems where the syscheckinterval mechanism for thread yielding doesn't work due to the locks in question not being "fair" on multicore platforms.
No, I understand the fairness problem - releasing the GIL for a whole millisecond is a workaround for exactly that issue. (Python must have suffered from this back on Windows NT 4, as that is where I first discovered this trick to fix a program that wasn't switching threads properly - before I added the time.sleep call to explicitly release the GIL and give other threads a chance to run before attempting to reacquire it, the program was running each thread to completion before starting the next one). It's a sledgehammer approach to the problem though and incurs a speed penalty even on platforms where the GIL thread scheduling is fairer. So it's better if we can find a way to ensure proper scheduling fairness across all platforms. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------