Threading in python

Aahz aahz at pythoncraft.com
Wed Dec 14 13:15:08 EST 2005


[BTW, please follow standard Usenet convention and attribute the quotes;
I've added them back in for you]

In article <mailman.2101.1134581605.18701.python-list at python.org>,
Carl J. Van Arsdall <cvanarsdall at mvista.com> wrote:
>Aahz:
>>Carl Van Arsdall:
>>>
>>> 1.  Who schedules which threads run and when?  Is this something left up 
>>> to the operating system or does python provide a mechanism for this?
>>
>> Strictly OS -- Python provides no control.
>
>I did some research yesterday, and I'd like some clarification.  So the
>OS handles which thread runs and when, however if one of the python
>processes currently holds the global interpreter lock, when the OS
>switches to a python thread that does not have this lock, this thread
>will do nothing.  Does this sound right?  Ultimately python does
>control what thread runs by controlling the global interpreter lock
>although its the underlying OS that handles all the context switching
>etc.

No.  Python simply uses a standard OS thread lock.  When a Python thread
gives up the GIL, the OS decides which thread acquires the lock -- it
could even be the same thread that released the lock.

>Because of this global interpreter lock does this mean its impossible to 
>get speed up with threading on multiple processor systems?  I would 
>think so because only one python thread can execute at any one time.  Is 
>there a way to get around this?  This isn't something I need to do, I'm 
>just curious at this point.

You either need to run multiple processes or run code that mostly calls
into C libraries that release the GIL.  For example, a threaded spider
scales nicely on SMP.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Don't listen to schmucks on USENET when making legal decisions.  Hire
yourself a competent schmuck."  --USENET schmuck (aka Robert Kern)



More information about the Python-list mailing list