Threading in python

[Carl J. Van Arsdall]

Hi everyone, I'm trying to use the threading module with python 2.2 and
I have some questions regarding python's threading.

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?

2. I've read that python threads don't like to allow other threads to
run except in certain situations, these would be situations where there
is sleep or I/O happening, is this true? If so, what are the cases in
which a python thread would not give up the processor?

3. Is there a way to which thread is running? I mean something a bit
more robust than a print statement inside the thread, I want to be able
to see when a context switch occurs, is this possible? The reason for
this is I will have threads deadlocked waiting for I/O and I am
interested to see how often context switching occurs.

Thanks in advance,

-carl

--

Carl J. Van Arsdall
cvanarsdall@mvi sta.com
Build and Release
MontaVista Software

[Aahz]

Re: Threading in python

In article <mailman.2057.1 134517248.18701 .python-list@python.org >,
Carl J. Van Arsdall <cvanarsdall@mv ista.com> wrote:[color=blue]
>
>I have some questions regarding python's threading.[/color]

These answers assume you're using CPython; Jython and IronPython have
different answers.
[color=blue]
>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?[/color]

Strictly OS -- Python provides no control.
[color=blue]
>2. I've read that python threads don't like to allow other threads to
>run except in certain situations, these would be situations where there
>is sleep or I/O happening, is this true? If so, what are the cases in
>which a python thread would not give up the processor?[/color]

There is only a single thread of Python code running at any time.
Calling out to external libraries (e.g. C code) can release the Global
Interpreter Lock. Python's standard I/O routines do this automatically
for you, but you're free to write your own code that does this (e.g.
mxODBC).
[color=blue]
>3. Is there a way to which thread is running? I mean something a bit
>more robust than a print statement inside the thread, I want to be able
>to see when a context switch occurs, is this possible? The reason for
>this is I will have threads deadlocked waiting for I/O and I am
>interested to see how often context switching occurs.[/color]

You'd have to write some kind of logging. You can use the logging
module.
--
Aahz (aahz@pythoncra ft.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)

[Carl J. Van Arsdall]

Re: Threading in python

[color=blue]
> These answers assume you're using CPython; Jython and IronPython have
> different answers.
>
>[/color]
This confuses me. What is CPython versus Jython and IronPython? I'm
using compiled source from python.org, would this be CPython?

[color=blue][color=green]
>> 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?
>>[/color]
>
> Strictly OS -- Python provides no control.
>[/color]

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.

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.



-c


--

Carl J. Van Arsdall
cvanarsdall@mvi sta.com
Build and Release
MontaVista Software

[Lawrence Oluyede]

Re: Threading in python

Il 2005-12-14, Carl J. Van Arsdall <cvanarsdall@mv ista.com> ha scritto:[color=blue]
> This confuses me. What is CPython versus Jython and IronPython? I'm
> using compiled source from python.org, would this be CPython?[/color]

CPython is the official distribution, the one you find on python.org
It's C and Python based.

Jython is the Python implementation targetting the JVM

IronPython is the Python implementation targetting the .NET CLR



--
Lawrence - http://www.oluyede.org/blog
"Anyone can freely use whatever he wants but the light at the end
of the tunnel for most of his problems is Python"

[Aahz]

Re: Threading in python

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

In article <mailman.2101.1 134581605.18701 .python-list@python.org >,
Carl J. Van Arsdall <cvanarsdall@mv ista.com> wrote:[color=blue]
>Aahz:[color=green]
>>Carl Van Arsdall:[color=darkred]
>>>
>>> 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?[/color]
>>
>> Strictly OS -- Python provides no control.[/color]
>
>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.[/color]

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.
[color=blue]
>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.[/color]

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@pythoncra ft.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)

[Peter Hansen]

Re: Threading in python

Jean-Paul Calderone wrote:[color=blue]
> On 14 Dec 2005 10:15:08 -0800, Aahz <aahz@pythoncra ft.com> wrote:[color=green]
>>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.[/color]
>
> Yes. Nearly as well as a single-threaded spider ;)[/color]

I'm confused about how a single-threaded spider -- even using Twisted!
-- could "scale well" on a multiprocessor machine (that's what SMP
means, right?) without using multiple processes. I believe that's the
scenario to which Aahz was referring.

-Peter