basic books/guides on multithreading programming?

[Cliff Wells]

On 17 Feb 2002 20:09:43 -0800
Andrae Muys wrote:

> Cliff Wells <logiplexsoftware at earthlink.net> wrote in message
news:<mailman.1013816158.26552.python-list at python.org>...
> > Thread-safety boils down to this: lock any /shared/ resource that might
be
> > /modified/ by a thread.  End of story.  You can get into all sorts of
> > debates about when these locks are necessary, but 99% of the time they
are,
> > and the other 1% isn't worth the effort to decide whether they really
are
> > or not.
> > 
> 
> "End of Story" is a rather interesting way to summarise the issues of
> Deadlock, Lock-ordering, Livelock, Starvation, Convoying, and
> Lock-Contention to name a few of the problems you may face moving from
> serial to parallel algorthims (although the last two only affect
> perfomance, not correctness).
> 
> I don't have the time to discuss these further atm, and I am not
> personally aware of a readily accessable text on concurrent
> programming.  Ben-Ari "Principles of Concurrent Programming" PH '82
> was the text used when I studied this back in university, however it
> is a little dry.  OTOH, I am very reluctant to recommend any of the
> language/library specific texts to someone without an existing
> knowledge of concurrency issues.  Even Kleiman, Shah, and Smaalders
> "Programming with Threads" (an excelent book, covers libpthread based
> programming in C/C++) gives rather preemptory coverage of the problems
> involved.
> 
> Unfortunately without an understanding of the problems, it is hard to
> understand/apply the solutions provided by the various
> languages/libraries described.
> 
> Cliff: Sorry I can't answer your question straight away, maybe check
> your local library (possibly uni-library) for a copy of Ben-Avi.  If
> you have any problems mapping the concepts he discusses to specific
> Python code I (and I imagine the rest of c.l.py) will do what I can to
> help.  Other then that, WHY do you feel you need threads?  Or is this
> just a "Something new to learn" question?
> 
> Tripp: If I sound a bit harsh, I'm sorry.  Understand that as someone
> with their name attached to a unexpectedly widely distributed tutorial
> on threading, I get *alot* of help requests from new programmers who
> think that threading is "just another library to learn", and approach
> it as such (with the inevitable trouble).  Your "End-of-story"
> statement was just more then I would reasonably let pass without
> comment.

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. 

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".

> 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?

-- 
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308  (800) 735-0555 x308