threads - use them as much as you can

[Ulf Wiger]

On Mon, 27 Nov 2000, David W. Bauer Jr. wrote:

>I wish I had gotten on this thread sooner.. I find that most people
>should stay away from threads in general because in order to use
>them you have to determine areas where parallelism can be exploited.  
>If you cannot do that well, then you will really derive no benefit
>from them.

I think this depends a bit on your perspective. If your programming
domain is e.g. math intensive stuff or editors, it's not immediately
obvious what Erlang's style of concurrency will bring.

Erlang is not really about exploiting parallelism in your programs.
The processes are a bit too heavy for that. It's more about threads of
control, which is a perfectly natural way of thinking about systems
like a telephone switch.

Once you have properly implemented control threads (Communicating
Sequential Processes, CSP, are, in my humble opinion the current state
of the art), you start realising that these threads can be used to
much more benefit than increasing the concurrency in your system:

- inherent in the "thread of control" concept is the philosophy of 
  doing one thing and doing it well: once you isolate independent
  (they don't have to be concurrent) tasks, you can assign a process
  to each, and this process has the luxury of concentrating on one 
  thing alone, which makes programming much easier.

- a thread also becomes a way of encapsulating exceptions. If a 
  programming error causes a process to crash, this will not
  necessarily affect anything else in the system, since the process
  was doing one thing only, and had its own memory. 

- finally, since we still have to detect process crashes, Erlang's
  concept of process linking and monitoring gives us a simple but
  powerful mechanism to structure our system so that it recovers 
  automatically from errors. This leads to the "let it crash"
  philosophy, so popular among Erlang programmers.

When I started learning Erlang, I made a list of the characteristics 
of OO, and a corresponding list of the characteristics of process-
oriented programming. I found that they were roughly equivalent in
terms of expressive power. With some more years of experience, I want
to add that this holds with a very important distinction:

OO wants to build on the commonalities between different components in
the system, and really maximize dependencies through inheritance and
the "everything is an object" motto.

The CSP model combined with functional programming basically does the
complete opposite: each process has its own environment, and the
majority of functions are totally side-effect free.

Personally, I am very much in favour of the latter, as it makes it
much easier to decomposition your problems and then reason about the
results.

/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