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

Jonathan Hogg jonathan at
Sat Aug 3 13:27:07 CEST 2002

On 3/8/2002 11:20, in article hOpJEiAY56S9EwZT at, "Robin
Becker" <robin at> wrote:

> Are the machine speeds comparable? I tested single thread speed as well
> on two freeBSDs with a speed diff around 6.5 for single thread I see
> only a factor of 2 in threads.

This makes sense. Thread switching is more likely to depend on fixed
timeslices and so I would expect smaller variance across different speed
machines running the same scheduler.

> bash-2.04$ python
> Counts:
> [364324, 154922, 14009, 14005, 14001, 13996, 13993, 13989, 13985, 13981]
> Total = 631205

This on the other hand is very interesting. The first couple of threads are
clearly dominating the CPU. I went back and ran again on my
FreeBSD box and noticed similar behaviour that I had overlooked before:

orwell% python
[54770, 55971, 30312, 15698, 15694, 15661, 15634, 15612, 15593, 15575]
Total = 250520

[15702, 15704, 15701, 15696, 15693, 15661, 15634, 15612, 15593, 15575]
Total = 156571

I presume this means FreeBSD switches to the first thread immediately after
it is started. This thread then gets to run at full tilt for a period of
time before it switches back to the main thread, that starts another thread
and then the two of them must share the CPU for a while, then the main
thread starts a third etc.

The other OSen I tested on didn't exhibit this behaviour so I guess they
must mark the threads as being runnable but not actually re-schedule until
the main thread hits the sleep.

Still can't figure out why FreeBSD is doing so much thread switching though.
It must be pretty inefficient.


More information about the Python-list mailing list