global interpreter lock not working as it should

Mark Day mday at
Fri Aug 2 17:48:12 CEST 2002

In article <ddc19db7.0208020705.4ef1e3e9 at>, Armin
Steinhoff <a-steinhoff at> 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".

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


More information about the Python-list mailing list