Concurrency, was Re: Doh! Stupid Programming Mistakes <humor>

Shane Hathaway shane at
Thu Oct 26 12:40:07 MDT 2006

Bryan Sant wrote:
> I'm not disagreeing that there are two distinct issues with
> concurrency.  My earlier post made the suggestion of using threads in
> tandem with a high-level language that provides proper memory
> protection and heap data scope isolation.  Given this situation I find
> that the built-in protection of OS processes is unneeded.  There are
> trade-offs with both approaches - child-processes and threads.

Threads provide no way to enforce a communication protocol.  You can't
write an interface specification that states all of the ways a parent
thread will talk to a child thread, since threads make it too easy to
manipulate inter-thread state out of band.  Even if you choose rules for
inter-thread communication and stick to them, future maintainers of your
code might accidentally violate those rules, receiving no warning for
doing so.  Your own refactoring could break your rules.  Breaking the
rules can lead to intermittent bugs such as race conditions and
deadlocks.  These bugs are the kind that only show up under heavy load,
and thus cost a lot of money to fix.

Using child processes forces you to define a communication protocol and
strongly encourages future maintainers to modify that protocol rather
than manipulate state out of band.  This mostly eliminates a whole class
of race conditions.  It does not eliminate deadlocks, but you can fix
deadlocks by analyzing the interprocess communication.

> I don't believe that Java's threading model is the best that could be,
> but I do find it more than worthy to utilize in the face of existing
> alternatives today.  Given Java's model (an others who have similar
> capabilities), I don't find any virtues in the child-process model of
> concurrent programming compared to threads.

I've seen what other programmers have done to my code.  They may be
brilliant coders, but their style is different, so they don't recognize
some of the patterns and accidentally break them.  If a broken pattern
leads to race conditions, then the problem often only shows up under load.

I've personally broken someone else's inter-thread communication pattern
without knowing it, and the breakage led to a month of diagnostic effort
on a production system by 4-5 developers.  It turned into a serious risk
to the business.  Today I prefer concurrency models that enforce a
communication protocol, unlike threads.


More information about the PLUG mailing list