threads

Andrew M. Kuchling akuchlin at mems-exchange.org
Thu Jun 3 22:51:07 CEST 1999


Hrvoje Niksic writes:
>Jeremy Hylton <jeremy at cnri.reston.va.us> writes:
>> The short answer is no.  The Python interpreter has a lock that
>> prevents allows only a single thread to execute at a time.
>
>Eek.  That's depressing.  Isn't supporting threads and not allowing
>simultaneous execution a bit weird?

    I don't think so, because the common case is probably not the one
where lots of work is being done in Python code.  Threads are probably 
being used for one of 2 purposes:

      1) I/O-heavy programs, where most of the threads are waiting for
some external event such as new data arriving on a socket.  Few
threads will run simultaneously at the same time, so it's not much of
a problem in this case.

      2) Computation-heavy programs, where you want multiple threads
to be scheduled on several CPUs.  In this case, your computational
heavy lifting is almost certainly not being done in Python, but in
wrapped calls to some C or Fortran library that does matrix math,
database access, or whatever.  If the person who wrapped the library
put in the proper Py_BEGIN_ALLOW_THREADS/END_ALLOW_THREADS
invocations, then other threads can run while the C code crunches, so
most of the threads spend most of their time not holding the
interpreter lock as they crank away.

      The single interpreter lock matters if you have several threads
all executing pure Python code at the same time; my suggestion is that
this is not the common case.  One exception might be Zope 2; I'm not
sure what the design of the threaded ZODB looks like, or if it avoids
this problem.

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
If you go looking for the Ladies... well, I don't know that that's such a good
idea. You might find them.
    -- Euryale, in SANDMAN #61: "The Kindly Ones:5"






More information about the Python-list mailing list