[Python-ideas] Remove GIL with CAS instructions?

[Nick Coghlan]

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 at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------