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

Jonathan Hogg jonathan at onegoodidea.com
Sat Aug 3 07:27:07 EDT 2002


On 3/8/2002 11:20, in article hOpJEiAY56S9EwZT at jessikat.fsnet.co.uk, "Robin
Becker" <robin at jessikat.fsnet.co.uk> 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 threads.py
> 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 threads.py again on my
FreeBSD box and noticed similar behaviour that I had overlooked before:

orwell% python threads.py
Counts:
[54770, 55971, 30312, 15698, 15694, 15661, 15634, 15612, 15593, 15575]
Total = 250520

Switches:
[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.

Jonathan





More information about the Python-list mailing list