Summary: E / Erlang integration

[Ulf Wiger (AL/EAB)]

> From: Michael FIG wrote:
> With both of these functions non-blocking, there is a 
> guarantee that deadlock is impossible.  That's the main 
> property of E programs that I'd like to achieve in
> this library.


The Erlang philosophy is to provide for synchronous wrappers around
asynchronous message passing. Waiting for a response can (and often is)
blocking. To reduce the "problem" of blocking, processes are made
lightweight enought that it should be feasible to create one concurrent
process for each naturally concurrent activity. Thus, the natural thing
to do when one needs a response from another process would be to stop
and wait for it.

My opinion is that it is dangerous to advocate completely non-blocking
semantics in complex programs, unless one makes abundantly clear what
problems can come of it. I think one of the biggest problems today in
the design of complex control logic is the inability to avoid complexity
explosion in the state-event matrix. It was suggested that E is able to
avoid this, and from a cursory glance at the code in this thread and at
erights.org, it seems plausible. I'm not convinced yet that it will be
intuitive enough, but maybe...

What I do know is that careless use of non-blocking programming in
complex control scenarios can very easily blow up in your face, leaving
you with an unintelligible and unmanageable mess. What's worse - very
few programmers involved in this type of programming are actually aware
of what causes these problems.

Even in Erlang, many programmers prefer 'cast' to 'call' for performance
reasons and/or fear of deadlock, but cast and call are semantically
different! If one needs a reply from the other process, a call is
natural. Deadlock can occur if two processes try to call each other at
the same time (this is the simplest form of deadlock), but changing call
to cast doesn't change this - deadlock can still occur, but it will be
immensely more difficult to detect.

There is a wealth of documentation on deadlock avoidance in the database
community. There are also good algorithms, such as the 'banker's
algorithm' to ensure freedom of deadlock. The reason why no DBMSs use
the algorithm is that it requires all resource dependencies to be known
up-front. Deadlock detection is relatively easy to implement, unless the
system is distributed. Deadlock prevention works in a distributed
setting, but may cause 'phantom deadlocks'. One has to pick the right
poison.

Erlang doesn't solve the problem of deadlock, just as it doesn't solve
the problem of complexity explosion. It has a programming model that
seems pretty intuitive and, if followed, tends to reduce (perhaps
eliminate) some of the very hairiest problems. You'll be left with some
smaller problems (unnecessary serialization, forgotten messages in
message queues, etc.) but these are relatively easy to detect and solve.

Regards,
Ulf W