Craig Latta <Craig.Latta at NetJam.ORG> wrote:
> 
> > ...threading often introduces locking.
> 
> 	Your best example, please?
> 

Oh man, a serious discussion?  Let me try:

	1. audiooss is a small multithreaded C library.  At a quick glance, it
seems to have about 5% of its commands dedicated to mutex locks and
unlocks.  And they aren't all correct!  I lost several hours one weekend
trying to track down one locking error, and suggested a quick fix for it
that seemed to work.  It's really hard to figure out whether that's the
last error or not, much less if that fix was correct.  Reasoning about
this stuff is tricky.

	2. PWS started crashing when each request was given its own thread.  I
don't know what ComSwiki does, but from talks with the author, it sounds
like the saving grace is that Smalltalk threads don't switch very often
(which IMHO should cause a revisit of the idea of using threads at all,
but he doesn't agree.)

	3. On the flip side, look at PluggableButtonMorph's
showSelectionFeedback variable, or the entirity of TextMorphEditor. 
This is the kind of saved state you have to implement if you don't use
threads.  This code seems a little awkward compared to method
invocations and local variables, but it's not all that bad, either. 
It's also quite easy to understand, I think.


But I'm not good with examples here, because I rarely deal with threaded
code!  I just seem to be one of the few people who's very happy about
it.  :)  Generally, threaded programs can be more elegant, but moving
from the first implementation to a correct implementation can be much
harder due to synchronization problems.  In a lot of the cases I've
seen, people advocate threads to solve problems that are already easy,
ie suggesting we nuke an ant and just deal with the fallout somehow.

Below is a longer post of mine to comp.lang.erlang, spelling this out
better than I've been able to recreate when I tried last night.  The
full thread is on groups.google.com if anyone is interested; the basic
response was "what kind of stone-age system are you working in?"  I
didn't answer, but I haven't used *any* system that's as nice as the one
they describe for multi-threading....


-Lex



======== on comp.lang.erlang ======

Others are strongly in favor of using multiple threads.  I have the
opposite opinion, mainly because the errors in multi-threaded programs
are so difficult to cope with.

There are two reasons for this difficulty.  First, the errors are
harder to find in multi-threaded programs.  In both design approaches,
you must reason about intermediate states between events in order to
find the errors, but in multi-threaded programs the intermediate
states are implicit.  In the event-driven design, those implicit
states are coded explicitly and can be examined directly.

Second, multi-threaded programs are very difficult to test.  It's hard
to generate a test case that makes one thread finish a certain step
just before another thread finishes a certain step; it's much easier
to generate a test case that makes a certain sequence of events
happen.


In another response, someone suggested using formal tools such as
model checkers to cope with these difficulties.  If a programmer is
using such tools, then I'm sure a lot of these problems go away.
However, the question remains interesting for people who don't have
such tools.  For such people, multi-threaded designs seem to be
an elegant way to introduce insidious errors.


Lex