basic books/guides on multithreading programming?

Andrae Muys amuys at shortech.com.au
Mon Feb 18 19:16:54 EST 2002


Cliff Wells <logiplexsoftware at earthlink.net> wrote in message news:<mailman.1014058862.32020.python-list at python.org>...
> Obviously you were aiming this statement at me, not Tripp ;)  I won't argue
> much (because you are correct), I will simply point out that these
> situations, while real, aren't that common in typical multithreaded
> applications (in my experience) unless the program is poorly thought out to
> start with.  They do however, make multithreaded programming seem
> _extremely_ daunting to a beginner.
>
> Speaking for myself, I've written several long-running multithreaded
> applications where I never _consciously_ considered these things.  I think
> once someone has developed a feel for multithreaded programming, these
> issues are handled at a different level in the designer's mind and explicit
> consideration of them usually isn't necessary (unless perhaps I'm just
> applying my own experience too broadly).  Maybe I'm just smarter than I
> give myself credit for <big wink>, as I've never run into the "inevitable
> trouble" you mention. 

Fair enough.  I just hate to think how many times I've seen:

pthread_mutex_lock(mutex);
/*!!! BUG: needs to be while loop or mut-ex is violated in critical
section. */
if (!condition) {  
    pthread_cond_wait(cond_var, mutex);
}
<critical section>
pthread_mutex_unlock(mutex);

let alone other more subtle bugs.

I had an email discussion with a beginner the other day, during which
I quickly sketched out a simple master-slave thread-pool class (C++
using pthreads).  The guy thought I had copied it out of a book, you
are correct with time you develop a feel for concurrency and
internalise the solutions to the various problems involved. 
(Ironically my sketch was text-book quality, ie. suitable for
illustration only, completely inadequate for production use ;)

> Considering all this, I'll take a different position: For beginners: don't
> worry about these issues now, but after becoming familiar with the basics
> of multithreaded programming (for which the standard Python docs should be
> sufficient), find a good book to deepen your knowledge.  That is to say,
> I'll qualify my earlier statement "end of story" with "for now".

And so we prove that reasonable people can differ :).

> > Everyone: Does anyone know of an accessable concurrency text?  One
> > that moves from discussing the basics (data-races, critical sections,
> > mutural exclusion, lock-order based deadlock, resource based deadlock,
> > etc) to the various solutions (mutex/cond-var, semaphore, monitor,
> > rendezvous) to the various design approaches (master-slave, pipeline,
> > work-pile, etc).  Possibly even a discussion of various performance
> > considerations (convoy's, wait-free synchronisation, cache-aliasing,
> > spin vs. blocking locks, etc).
> 
> I would certainly like to see a good discussion of these.  Do you have a
> URL for the tutorial you wrote?

I will be rewriting it over the course of the next couple of months. 
It was written as a short-form talk for our local home-unix user
group.  I never expected it to be distributed as far as it has. 
(apart from anything, the attached code is very poor quality, and I
really should write some production quality code to supliment the
tutorial examples).

http://www.humbug.org.au/talks/pthreads/

Andrae Muys



More information about the Python-list mailing list