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

[Jonathan Hogg]

On 6/8/2002 0:57, in article mailman.1028591832.7036.python-list at python.org,
"anton wilson" <anton.wilson at camotion.com> wrote:

>> 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.
>> 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.
> 
> well, i don't really think it's runnable, becuase the system call used by
> pthread_cond_wait takes it off the run-queue until a signal is delivered.

Sorry, I meant that thread B will have been unblocked by a previous
pthread_cond_signal during one of the release-reacquire points of thread A.
It's not been run yet but it is now runnable.

So when the timer interrupt occurs, thread B can be run. The problem being
that it immediately blocks again since thread A still owns the GIL.

At least it seems like a problem. As Tim pointed out, who knows at the
moment without being able to run some serious tests on a SCHED_RR system.

Jonathan