Thread imbalance

[Bryan Olson]

Peter Hansen wrote:
> Ivan Voras wrote:
>> Python is bad for concurrently executing/computing threads, but it 
>> shouldn't be that bad - do you have lots of compute-intensive threads?
> 
> Just in case anyone coming along in the future reads this statement, for 
> the record I'd like to say this is obviously a matter of opinion or 
> interpretation, since in my view Python is *excellent* for threads

Ivan already gave his answer: the GIL. The GIL is no real problem
on single processors. As commodity machines go to
multi-poly-hyper-cell-core, or whatever they call it, the GIL is
becoming much less attractive.

There are other issues of note:

As the OP's problem points out, Python threads don't offer any
priority control.

Timeouts on the threading module's Condition objects are
implemented by active polling. Timeouts in threading.Event and
Queue.Queue are implemented via threading.Condition so they
inherit the polling implementation.

A thread can wait on just one
Lock/RLock/Condition/Semaphore/Event/Timer at a time. There is no
analog of Win32's WaitMultipleObjects(). As an example, suppose
we wanted to implement timeouts without polling by waiting for
either a Semaphore or a timer. With Python's standard thread and
threading libraries, there's no good way to do so.


-- 
--Bryan