[Python-ideas] Remove GIL with CAS instructions?

Kristján Valur Jónsson kristjan at ccpgames.com
Wed Oct 21 15:12:38 CEST 2009



> -----Original Message-----
> From: python-ideas-bounces+kristjan=ccpgames.com at python.org
> [mailto:python-ideas-bounces+kristjan=ccpgames.com at python.org] On
> Behalf Of Nick Coghlan
> Sent: 21. október 2009 12:31
> To: Sturla Molden
> Cc: python-ideas at 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



More information about the Python-ideas mailing list