Home Original page

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

Armin Steinhoff a-steinhoff at web.de
Thu Aug 8 04:47:55 EDT 2002 
bokr at oz.net (Bengt Richter) wrote in message news:<aisc8d$tmv$0 at 216.39.172.122>...
> On 07 Aug 2002 14:03:50 +0200, loewis at informatik.hu-berlin.de (Martin v. =?iso-8859-15?q?L=F6wis?=) wrote:
> 
> >a-steinhoff at web.de (Armin Steinhoff) writes:
> >
> >> In the moment it makes no sense to use the 'Python threads' for
> >> POSIX systems 'if and only if' you need performance (or real-time
> >> performance).
> >
> >Whatever changes you make, they can't increase the performance. If you
> >need performance, you better avoid threads. On a single processor,
> >threads can only slow down the entire computation.
> >
> If you're talking about the compute-bound situation, as we have been,
> yes, but typically all is not computation. I don't expect you mean that
> in general multithreading always slows down a *system* ;-)
> 
> I.e., system throughput depends on timely cooperation with hardware,
> and a good threading system makes that easier to program. Even a suboptimal
> threading implementation can beat a single thread if the latter doesn't poll
> adequately (i.e., in place of ceval's polling, thereby effectively doing its
> own multithreading), or have signal handler help, etc. And polling adequately
> can't beat non-polling event-driven help from an OS (with some exceptions for
> high fequency polling).


Correct ... a PC in general a unit with multiple processors.
Count the number of peripheral mikroprocessors and controllers (VGA,
disk a.s.o ) ... all are running concurrently (physically)

Regards

Armin 

> 
> Regards,
> Bengt Richter
More information about the Python-list mailing list