global interpreter lock not working as it should
a-steinhoff at web.de
Sat Aug 3 12:09:49 CEST 2002
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
The OS doesn't realease the GIL ... would be a desaster if the OS
would do it.
Hope point 3) will never be true.
> 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
More information about the Python-list