why concurrency in the first place?

[Ulf Wiger]

On Mon, 5 Feb 2001, Karel Van Oudheusden wrote:

>I know this may sound like a naieve question but I would like to
>have a thorough answer any way :) "Why does an (Erlang) programmer
>have to program his application with concurrency explicitly in
>mind?" I also know (think) that this was the main intention of the
>Erlang language.

You bring up an important point.


Here's an example, from the world for which Erlang was designed:


In a telephone switch, a phone call is set up via control signals
on a certain interface. Many calls are set up via the same interface.

A handy model for a call setup activity is to split it into two
parts, normally called the A (originating) and B (terminating) sides.
To make things simple, lets say that we have the following components:

a) signaling control link for A side
b) A side "half-call"
c) B side "half-call"
d) resource management for A side interface
e) resource management for B side interface
f) signaling control link for B side

(We've skipped routing, address analysis, and some other fun stuff)

It's very easy to apply an Erlang process model to (a), (b), (c) and
(f), actually. It nicely depicts the built-in concurrency in the
problem. Modeling the problem as objects which may or may not be
concurrent in the real world does not aid understanding in this case.

Looking into, say, the A side half-call, you will find several
independent state machines. They are not concurrent in one sense, as
their state transitions are tightly coupled, but you can, for example
replace one (protocol) layer 3 FSM with another. As it turns out,
implementing these FSMs as separate processes in Erlang would be a
mistake. 

Looking at resource management, (d) and (e), it's natural to view them
as two instances of resource management. In the implementation, they
are probably either one or two processes, depending on various issues
(interface distribution, for example.)


Bottom line?

As we design these systems, we try to tell programmers to structure
their code so that specific use of concurrency constructs is limited
to a small part of the code.

The Erlang model of concurrency helps us tie the problem specification
to a concrete behaviour, while maintaining a very high level of
abstraction.

Since the Erlang programmer is offered a very "clean" programming
environment -- no side effects, no other program poking around in your
variables, etc. -- it's easy to concentrate on specifying the program
logic, instead of worrying about administrative stuff (memory
management, critical sections, and so on.)


Then, you can quite easily map your program logic to a concrete
implementation, using the built-in concurrency and
distribution support. Thus, the step from "abstract" specification to
"concrete" specification is very small.




>Isn't it easier (cfr. Haskell) to free the programmer (=designer)
>from this burden?  If a programmer has to specify it (as is the case
>in Erlang), he will typically overspecify his system (even if the
>processes are light weight).

My experience is this:

If you spend too much time on your abstract model, without tying it
down to a concrete implementation, you will most likely overspecify
the system. If you structure your code reasonably well, you will be
able to change the concurrency model several times along the way
without much impact on the majority of your code; but putting it
together and watching it run will also help you find the logical flaws
in your "pure" code.




>Process spawning and message passing are sources of impureness in
>Erlang.  This was a pragmatic choice of the Erlang founders.  Is
>this because it is (still) difficult for pure functional compilers
>to do a good job on extracting optimal concurrency from an initially
>pure functional specification?  Does the Haskell compiler do a good
>job on this?


Getting the level of concurrency just right in a product such as the
AXD 301, cannot be done by a compiler. I can almost guarantee that you
will not get it right the first, or even second or third, time. You
simply have to work the problem enough to figure out what works best.

(http://www.ericsson.se/datacom/products/wan_core/axd301/index.shtml)




>I also want to make the following statement (please give feedback):  
>"It is always easier to specify a system without explicit
>concurrency in mind."  For example:  programming in Haskell (which
>is almost similar to specifying) is done in a
>concurrency-independent way leaving the eventual implementation to
>have any degree of true concurrency, depending on what the compiler
>decides is best.

At one level of specification (abstract specification), you're right:
explicit concurrency shouldn't enter the picture.

Purely functional languages do very well in this area. But when taking
the abstract model one step further to "concretion" (a terrible word
that I just learned), things tend to get messy if your language
doesn't support explicit concurrency.




>I have looked at the "Erlang/OTP R7 - speed test of new inet driver"
>code the last couple of days.  It can be found at:
>http://www.erlang.se/r7_inet_speed/index.shtm.  I am relatively new
>to Erlang.  I must say that this code is not very readable.  I would
>typically choose to use more modules in my code.  And I am very
>astonished about the different (light-weight) processes that are
>spawned every now and then.

Just to be clear, what you're looking at there is not an abstract
specification, nor a concrete specification -- it's deep-core hacking
of functionality that you normally keep a safe distance away from any
high-level modeling tools.

I believe your point, though, is that the code could be written
differently without loss of performance, but greatly benefiting
readability. You're probably right. Too much industrial product code
is butt-ugly when it could be a thing of beauty (the same thing goes
for my programs.) This is something one has to learn to live with to
some degree. This is how it usually works:

1. You have an idea; you don't know if it will work
2. You slap together a prototype and run it
3. Lo and behold: the idea worked
4. Now you want to make it beautiful...
   -- Sorry, no time -- lots of other problems to attack;
   if it works, don't mess with it.

Once in a while, you actually _do_ get the time to make something
really beautiful. Those are the moments...

/Uffe
-- 
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB