threads - use them as much as you can

[Thomas Lindgren]

> Mmm, tempting but not as easy as it looks like: Erlang processes are really
> processes (no memory shared with other processes), while Java threads
> are really threads (one of them can change a bit of memory that another
> thread is using).

An Erlang process need not be an OS process or even a thread. We must
distinguish language-level processes from OS-level processes.

A thread is often considered a light-weight process (i.e., cheap to
create, schedule or destroy) enclosed by an operating system process,
which handles resource management, access control, address space
mapping, etc.  We can call this the "administrative" view. (Note that
two OS processes often can share memory using various forms of
trickery, e.g., with shmem() or mmap(), so shared-memory == thread vs
message-passing == process is not a valid categorization.)

Erlang/OTP uses something simpler than the administrative view. In
the current Erlang/OTP implementation, an Erlang process is simply a
record with pointers to the memory allocated by the process (heap,
stack, ...).

When an Erlang process is scheduled to run, the runtime
system loads the appropriate data and jumps to the indicated
function. 

When the Erlang process yields (by hanging in 'receive' or by its time
slice/reduction-counter going to zero), the process information is
stored back in the record again whereafter a new process record is
selected to run. Note that the running process is not interrupted, but
may yield gracefully at some well-known points in the code.

Thus, an Erlang/OTP node runs entirely _sequentially_, but multiplexes
Erlang processes internally. To the user, this seems like concurrent
execution.  The disadvantage of this solution is that it does not
transparently exploit SMP.

However, you can overcome that by running several Erlang nodes on a single
SMP host, communicating using distributed Erlang or perhaps sockets.

Furthermore, there are efficiency advantages to the current
model. First, since scheduling occurs only at safe points, there is no
need to protect updates to shared data with locks. Second, since
Erlang does not permit messing around with the stack, there is no need
to allocate huge areas per thread for stack space. (The latter is an
advantage of the language, rather than the implementation.)

Erlang/OTP processes are thus in fact even cheaper than OS-level
threads, or Java threads. Not to mention more convenient than either.

			Thomas
--
Thomas Lindgren					thomasl+junk@REDACTED
Alteon WebSystems				http://www.bluetail.com