-----Original Message----- From: python-ideas-bounces+kristjan=ccpgames.com@python.org [mailto:python-ideas-bounces+kristjan=ccpgames.com@python.org] On Behalf Of Nick Coghlan Sent: 21. október 2009 12:31 To: Sturla Molden Cc: python-ideas@python.org Subject: Re: [Python-ideas] Remove GIL with CAS instructions?
- The GIL has consequences on multicore CPUs that are overlooked: thread switches are usually missed at check intervals.
In the rare case where none of those threads are releasing the GIL for any other reason, time.sleep(0.001) works wonders. Yeah, it's a wart, but not a particularly difficult one to deal with.
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. K