[Python-Dev] "Fixing" the new GIL

[Kristján Valur Jónsson]

> -----Original Message-----
> From: python-dev-bounces+kristjan=ccpgames.com at python.org
> [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf
> Of Antoine Pitrou
> Sent: 16. mars 2010 12:00
> To: python-dev at python.org
> Subject: Re: [Python-Dev] "Fixing" the new GIL
> 
> 
> Hi Kristján,
> 
> > In the new GIL, there appear to be several problems:
> > 1) There is no FIFO queue of threads wanting the queue, thus thread
> > scheduling becomes non-deterministic
> 
> Thread scheduling has always been non-deterministic.
Yes, but not the scheduling of "which thread has the GIL" which is what we are talking about.  With a gil, you have neutered the non-deterministic OS scheduler and forced the system to _effectively_ schedule threads as you with them to be scheduled.  The key to this is implementing your GIL in such a way that you (and not the system) chooses which threads runs next.  On Windows it works in a nice, determinitstic FIFO order becoause that's how the underlying Event object is supposed to work.  under pthreads, we rely on the behaviour of the condition variable which _probably_ is well behaved in this manner too.

> 
> > 2) The "ticking" of the GIL is
> > now controled by a condition variable timeout.  There appears to be
> > no way to prevent many such timeouts to be in progress at the same
> > time, thus you may have an unnecessarily high rate of ticking going
> > on.
> 
> Unless there's a bug, no, there isn't.
You're right, I had forgotten about "gil_switch_number".  Never mind.

> 
> > 3) There isn't an immediate gil request made when an IO thread
> > requests the gil back, only after an initial timeout.
> 
> This is what we are looking to fix (perhaps).
> 
> > What we are trying to write here is a thread scheduler, and that is
> > complex business. K
> 
> I would have rephrased:
> "What we are trying to avoid here is a thread scheduler".

I can't argue with that, but I'm afraid that in the end, you have to.  Python threads do behave very much in the same way as stackless python tasklets do.  They own the cpu until they volounteeringly give it up.  You want to decide, then, which of the threads next gets its turn.  You are working on a completely different level than what the OS usually uses for its scheduling (timeslices, IO) so _you_ have to be in control.  By a happy coincidence, in the past on a single CPU, the old GIL did give us this, without us being explicit about it:  FIFO execution of tasklets.  This fell out as a byproduct of the very simple way that the GIL was implemented, using a single Condition variable.  Now that we have a different mechanism, _where threads time out_ on the condition, this behaviour no longer falls out of the implementation on its own.  It may turn out, in this new, more complicated world, that you have to explicitly schedule the threads, by chaining them and giving each their own condition to wait on.

Btw, if you want to take up a private converstaion with me, I'd like to point out to you some problems with the Windows version of the Condition variable :)

Cheers,

Kristján