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