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