Teaching Erlang as part of a paper -- advice sought

[Jay Nelson]

Richard wrote:

 > The question is "how do we look at a problem and see the
 > concurrency there", and if anyone has any recommendations
 > I'd be very pleased to get them.

I have always concentrated on "processing granularity" for
concurrency.  To get multiple things done simultaneously,
it is essential that there are no dependencies among them.
The idea is to reduce any block of code to the minimal amount
that (a) computes a particular task result or performs a verifiable
task and (b) can succinctly communicate that result to another
piece of the system.

There is a three way trade off of processing time, memory used,
and communication bandwidth.  If any of these three become a
bottleneck, the code is pushed into the other two.  Trading
processing time for memory and communication is a form of
compression.  Trading memory and communication for processing
time is a form of resiliency or responsiveness (two separate
concepts).

When the granularity of processes is small enough, they fit
more tightly in a container just like sand versus pebbles in
a jar.  Failure of a process is easier to deal with because the
scope of the concept it covers is smaller, and the ability to
reason about the recovery replacement is simpler.  If many
processes are progressing while a few fail and recover, the
impact is not really noticeable in the system as a whole.

Granularity of computation, data and communication is in my
mind the essence of concurrency.

jay