[Tutor] Python threads

Danny Yoo dyoo at hkn.eecs.berkeley.edu
Thu Jun 10 18:14:21 EDT 2004

On Wed, 9 Jun 2004 tpc at csua.berkeley.edu wrote:

> I have created a function called determinePlaytimeInSeconds that, given a
> tuple of, say, 20 tuples consisting of filename and URI:
> (('filename01', 'http://hostname/audio/filename01.mp3'), ('filename02',
> 'http://hostname/audio/filename02.mp3'), ('filename03',
> 'http://hostname/video/filename03.wmv'), etc...)
> passes each tuple to a threaded class called FileReader.

Hi Tpc,

I have to ask a silly question: why is the class threaded?  I don't see
the need for the threading here.  Since threaded programming can be
complicated, it might be a better idea to avoid it for this particular

Jon Ousterhout (creator of Tcl) has said that threads are the wrong tool
for many coding problems:


And if he says threads are hard, that's a bad sign.  *grin*

Anyway, let's look at the code.

> def determinePlayTimeInSeconds(results):
>         threadList = []
> 	for result in results:
>                 fileReader = FileReader(result)
>                 fileReader.start()

Ok, so a new 'thread' called fileReader starts up.

>                 threadList.append(fileReader)
>         #while activeCount() > 1:
>                 #sleep(1)
>         for fileReader in threadList:
>                 (fileType, playtimeInSeconds) = fileReader.getPlaytimeInSeconds()

The problem here is that there is no guarantee that fileReader has started
processing files by the time we get to the expression:


If we want to maintain the threading paradigm, we need to use
"synchronization".  That is, we need to set up some kind of traffic cop
that will cause our program to wait until the fileReader has finished
processing the file.  In pseudocode, we'd write something like:

    while fileReader hasn't finished processing yet:
        wait until it has notified us that it's done

These 'synchronization' primitives live in the 'threading' module, and are
named things like 'Condition' or 'Lock' or 'Semaphore':


and we'd use these synchronization objects to implement the idea of "wait
until the fileReader is done"... but, again, this seems like overkill to
attack this problem with threads.  Can you do it without them?

If you really really want to use threads, we can continue talking about
it, but I just get the feeling that the complexity just isn't worth it

Good luck!

More information about the Tutor mailing list