On Thursday 14 February 2002 07:57 am, you wrote:
> 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.
>
	Augh, Mutex Locks. Such low level threading control should be labeled 
"Here Monsters Lie".

	Monitors are definitely easier.

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

	Oigh, well, that's not a very good reason for broken code... <:)
>
> 	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

	Personally, I find threading to be a issue designed last. About the only 
threading most programs need is when A) Something takes a very long time to 
render onscreen  and B) does lots of disk access.

	If you got a good compartmentalized design, then one can usually go back 
and add threads to the necessary parts of A & B above.


	Daniel Joyce