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

Armin Steinhoff asteinhoff at web.de
Wed Aug 7 14:58:53 CEST 2002


Armin Steinhoff wrote:
> 
> anton wilson <anton.wilson at camotion.com> wrote in message news:<mailman.1028671934.28426.python-list at python.org>...
> > On Tuesday 06 August 2002 03:38 pm, Martin v. Loewis wrote:
> > > anton wilson <anton.wilson at camotion.com> writes:
> > > > > > The timer tick does happen 100x per second and since python gives up
> > > > > > the lock every 10 us or so, it's really not a huge coincidence for
> > > > > > an overlap. I just don't really like the reliance on this
> > > > > > coincidence.
> > > > >
> > > > > Accept it. It is meant to work this way.
> > > >
> > > > I understand that, but still . . . you have to agree that the ratio here
> > > > is pretty horrible for certain systems even if it was supposed to be
> > > > cross-platform. It works as it should, but for this particular OS, it
> > > > could be helped along. There's nothing wrong with being more efficient if
> > > > you can be and it won't hurt any design goals.
> > >
> > > I'm all in favour of efficiency. However, adding more thread switches
> > > is likely to hurt efficiency, instead of increasing it.
> >
> > This is true; however, we're still making tons of system calls to lock,
> > unlock and signal every ten byte-codes . . . system calls aren't very fast
> > either because you have to drop into kernel mode (also a switch). So my
> > stance is, it would be nice if all that work weren't completely in vain, and
> > actually served a purpose at least half of the time. So for systems who
> > really care about decreasing switching in the name of time,
> > sys.setcheckinterval(x) exists.
> 
> As an intermediate solution I have only inserts two
> lines in cevel.c  ... here some performance numbers.

Grrrrr ... wrong numbers. The test script contains a random delay.
So simply forget it ...

Armin


> 
> Performance unmodified:
> 
> time ../../python test_threading.py
> .....
> task <thread 2> done
> <thread 2> is finished. 0 tasks are running
> all tasks done
>     4.16s real     0.14s user     0.02s system
> #
> 
> Performance after inserting
> 
>     if(PyThread_get_thread_ident() > 1)
>          sched_yield();              //yield only if more then one thread is running
> 
> time ../../python test_threading.py
> ................
> <thread 2> is finished. 1 tasks are running
> task <thread 1> done
> <thread 1> is finished. 0 tasks are running
> all tasks done
>     2.66s real     0.16s user     0.02s system
> #
> 
> The performance is increased by ~90 %
> 
> Armin
> 
> >
> >
> > Anton



More information about the Python-list mailing list