Threading problem
David Bolen
db3l at fitlinxx.com
Wed Apr 3 19:53:42 EST 2002
Gustavo Cordova <gcordova at hebmex.com> writes:
> > The Python global interpreter lock requires that even with native
> > threading, only one thread is actually interpreting Python code at any
> > moment in time. The net result of this is that while threading is
> > excellent for overlapping I/O, it won't efficiently distribute CPU
> > amongst processors. That's because if you are CPU bound, then you are
> > stuck in Python code execution, and only one processor can be doing
> > that at any given moment in time.
> >
>
> This is evil :-(
It's trade-offs. It may be less than desirable for multi-processor
utilization, but it actually carries quite a few implementation
benefits for the Python core, as well as minimizes the performance
overhead for maintaining native threading support. In all but SMP
cases, it works quite well (barring non-cooperative extensions).
The only way to change this would be to push all the interlocking down
to the individual data structure/object levels, which would be no
small feat (at least for the current CPython implementation), but one
which I believe gets discussed from time to time. Wouldn't hold my
breathe though :-)
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db3l at fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
More information about the Python-list
mailing list