SMP, GIL and Threads

Aahz aahz at pythoncraft.com
Fri Dec 16 17:59:01 EST 2005


In article <1134749141.719835.206810 at z14g2000cwz.googlegroups.com>,
catsup <ramadon.rexx at gmail.com> wrote:
>
>I have an app written under version Python 2.3.5.  The problem I'm
>having is that it hangs on one of its threads.  The thread that hangs
>does updates to a standard dictionary shared with another thread that
>only reads this dictionary.  This app works beautifully on a single
>processor boxes in my testing environment, but this problem quickly
>occurs when the software runs on a dual cpu SMP blade server with
>hyperthreading turned off, Windows 2003 server.

Hrm.  This is either a Python bug or a bug in your application; I'd bet
on the latter, but the former is possible.  (That is, there have been
bugs in previous versions of Python that were at least theoretically
stimulatable on single-CPU machines but in practice only showed up with
SMP machines.)

To find out which this is, you need to provide a reasonably small chunk
of code that demonstrates the problem.  Until you prove otherwise, we'll
have to assume that it's a bug in your code, because many other people
are running threaded applications just fine.  You might check the dev
logs and see if any thread bugs were fixed for 2.4 (or just try using
2.4 to see whether that helps).

>I do not bother using application level locks because I figure the GIL
>is going to do the job for me, and because with one thread doing
>updates and the other only reading, things remain consistent logically
>for the app.  The app will not have a problem if the dictionary changes
>just before it does a read.

This is usually safe.

>I have searched this group on this subject and seen one warning against
>sharing objects between threads.  I don't recall every writing a
>threaded app that didn't share data between threads in some way.  I've
>also seen a recomendation in this list against using threads at all
>with Python.  I'm hoping that is an extreme view and not general wisdom
>here.  Python has never failed me when analysis indicated that it would
>be the correct tool for the job.

What the warning actually means is that the only shared object between
threads should be a Queue; you pass other objects between threads using
the Queue, so that only one thread at a time uses the non-Queue objects.
-- 
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