threads - use them as much as you can

[Maurice Castro]

Sean Hinde writes:
> 
> Agreed, but there appears to be a serious amount of will power and
> resourcing behind this. At the moment attempting to write anything
> asynchronous and multithreaded seems to be extremely painful because the
> Java language and runtime provide only hindrance. If the platform is fixed
> sufficiently to allow "normal" Java programmers to do this stuff safely then
> maybe it will become the platform of choice for "responsive" non blocking
> clients and servers..?
> 

I am prepared to make the following bold statement:

	Adding stuff to Java is not likely to bring the benefits of Erlang. 

This statement can be justified by realising that the strengths of Erlang
come as much from what has been left out of the language as what
has been included. 

The key item left out of Erlang that aids the development of concurrent
applications the absence of shared memory between processes/threads (I will
come back to ETS tables later). 

Shared memory is almost always the hardest resource to manage in a
concurrent system as it requires each programmer to be mindful of the
*conventions of use* of that memory. Any programmer interacting with
that memory item who violates the conventions or if the conventions are
flawed will be able to directly damage the other users of the shared
resource. Furthermore, as it is memory, it tends to be hard to track
down the misuse. 

Erlang avoids these problems in 2 ways. The first is that without
shared memory a process / thread cannot directly upset the internals of
another process / thread.  The second is that every shared resource in
Erlang has a managing process so that it is generally easy to find
where all the access rules are for a particular shared resource.

The introduction of shared objects only partly aids the shared memory
user. To some extent shared objects allow the access rules to
be localised, however, this usually requires the author of the shared
object to take into account not only the single process behaviour (ie
all that our Erlang shared resource manager needs to) but the interactions
between multiple processes accessing the object. Furthermore, if the 
objects lock resources deadlock can easily be achieved by the users of
the objects attempting to reserve access to shared objects in different 
orders. This is made still worse as programmers are encouraged to believe
that the operation of an object can be rewritten without regard for the
use of an object so long as they leave the external interface alone. 

So if a Java programmer wants the benefits of Erlang all s/he has to do
is give up sharing, use message passing exclusively and avoid in place 
updates. (Ooops, forgot Last Call Optimization :) )

	Maurice Castro

PS. ETS tables can currently be modeled as an Erlang process accessed via
a set of access functions.