global interpreter lock not working as it should

[Armin Steinhoff]

anton wilson <anton.wilson at camotion.com> wrote in message news:<mailman.1028307135.32293.python-list at python.org>...
> 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.

No ... scheduling events are not only bound to the system clock. Such
events can also be: interrupts (also created by the clock), signals ..
blocking IO actions.

> 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)

The OS doesn't realease the GIL ... would be a desaster if the OS
would do it.
Hope point 3) will never be true.

Armin

 
> 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