global interpreter lock not working as it should

[anton wilson]

On Friday 02 August 2002 11:48 am, Mark Day wrote:
> In article <ddc19db7.0208020705.4ef1e3e9 at posting.google.com>, Armin
>
> Steinhoff <a-steinhoff at web.de> wrote:
> > I see your point. The release_lock / acquire_lock make only sense if
> > the threads have different priorities. But all Python threads have by
> > default the same priority ... so it makes absolutely sense to include
> > the sched_yield for a fair scheduling.
> >
> > Without the sched_yield ... a Python thread can catch the CPU for
> > ever. (if not preempted by a task with a higher prio)
>
> In many (most?) schedulers, if you have other eligble threads at the
> same priority as the running thread, those other eligible threads will
> all get run eventually.  This is commonly done by using some periodic
> timer to give the scheduler an opportunity to reschedule and pick
> another thread at the same priority, or perhaps notice higher priority
> threads that have become eligible (vs. systems that immediately
> reschedule when a higher priority thread becomes eligible).  That time
> period is often known as a "time slice".
>

This is true. Therefore, the only time another thread WILL grab the GIL under 
Linux is if 

1) the GIL is released by the currently running thread
2) the thread that just released the GIL depletes its timeslice before it
   can grab the lock again 
3) the OS notices the process has depleted it's timeslice and the yanks       
   it from the CPU (this happens every 100 times per second by default on an  
                    i386)
4) the waiting thread that recieved the GIL release signal is chosen to run

Therefore, we now have a large set of coincidences for CPU-bound python 
threads. The only reason it works at all is because it happens 100 times per 
second and the GIL is released frequently by default. So there is a 
sufficient probability that these 4 cases will happen simultaneously.

> And some schedulers even allow lower priority threads to run
> occasionally to prevent starvation.
>
> -Mark