Python threading (was: Re: global interpreter lock not working as it should)

[Armin Steinhoff]

Jonathan Hogg <jonathan at onegoodidea.com> wrote in message news:<B972E7AC.F13F%jonathan at onegoodidea.com>...
> On 4/8/2002 11:14, in article m31y9fj5hp.fsf at mira.informatik.hu-berlin.de,
> "Martin v. Loewis" <martin at v.loewis.de> wrote:
> 
> > Jonathan Hogg <jonathan at onegoodidea.com> writes:
> > 
[ clip ..]
> 
> I had it in my head that, when the timer interrupt for the timeslice fires,
> thread B wouldn't be runnable because it's waiting on the GIL. But of course
> it *is* runnable because it's not waiting on the GIL, it's waiting on a
> condition saying that the GIL has been released sometime in the past.

Hmm ... but why should the scheduler suspend a running thread if its
timeslice isn't exhausted??  (This is what sched_yield() would do ..)

> If it
> was waiting on the GIL then the timer interrupt would do nothing and when A
> hit the next release-reacquire point the scheduler would see that A had gone
> past the end of it's timeslice and could switch to the now-runnable B.
> 
> I'm not sure if this is what is happening or not, but it seems plausible. In
> which case the problem is, in some respect, that B has been made runnable
> before the timeslice for A has expired but can't actually do any work as it
> will immediately block again. The thread scheduler has no way of knowing
> that B hasn't been given a fair go and so presumes that B has decided to
> block voluntarily and that A can get back to work.
> 
> Inserting an explicit yield between the release and re-acquisition of the
> lock would be a terrible idea as it would defeat the scheduler and hammer
> performance.

Yes ... sched_yield would place the calling thread as a runnable
thread at the end of the chain of all runnable threads ... and this
every 10 byte codes =:-/

Well .. this isn't optimal :)

> My thought would be that the trick is to not release the GIL
> while the running thread still has timeslice. Then when you do release the
> GIL, the scheduler would (hopefully) immediately switch to the next waiting
> thread.
> 
> God knows I'm no pthreads expert, but I know you can query the scheduling
> policy of the current thread. So if it's SCHED_RR, can one ask how much
> timeslice is left? If you could do that then you could just skip over the
> release-reacquire.
> 
> Hmmm...
> 
> Oh! Apologies to Armin for being overly dismissive before.

I have no problems with it :) But I see at the and of this discussion
that sched_yield() isn't the solution.

Armin

> 
> Jonathan