Chris Thomas wrote:
> 
>...
> >
> > Python's threads are crude because although they are OS scheduled, only
> > one thread can access the Python internals at a time. This is seldom
> > (never?) a problem on a mono-processor machine but becomes a big problem
> > on a multi-processor one.
> 
> It's a problem on single-processor machines too. If thread A wants resource
> Z, and thread B wants resource Z, and thread A grabs resource Z before
> thread B, thread B has to wait until thread A is done with resource Z.

That's true in any threading model.

> You really want to let both threads complete as soon as possible, so you
> want locks to be as finely-grained as is reasonable, even on
> single-processor machines. 

To the Python programmer, locks are held for less than the time it takes
to execute a single bytecode. And if the bytecode does something slow
(e.g. networking or file system access) then it gives up the lock if it
is threadsafe (which Pythons networking and file system objects are).

You could only have a problem if you use some C extension that is not
threadsafe or if you tricked the Python runtime into doing something
that is usually not computationally expensive but in one circumstance
happens to be (e.g. multiplying to very large numbers would probably be
a blocking operation).

 Paul Prescod