time for a truly threaded Erlang?

[Ulf Wiger]

On Fri, 13 Dec 2002, Leonid Timochouk wrote:

>But is there any need for a truly threaded Erlang? The
>native Linux threads (in the current version) are pretty
>heavy-weight, and not much different from full-fledged
>processes (indeed, the "fork" syscall in Linux is just a
>specialisation of "clone" which is used to create kernel
>threads). The cited posting mentions some improvements in
>"clone", but the relatively high cost of thread creation
>(compared to Erlang processes) would probably still be an
>issue.

It was the mention of starting and stopping 100,000 threads
within 2 seconds on 2-CPU machine that caught my attention.
Assuming a perfectly even load split between the CPUs (which
is probably not the case), this would mean 40us to start and
stop one thread, and that's not so terribly different from
Erlang's performance. Granted, you must do a bit more than
just create a POSIX thread -- a global process table needs
to be kept, and the Erlang process metadata must be
initialized. Still...

In the old Multi-Pro Erlang (Pekka Hedqvist's thesis), one
suggestion was to run scheduler groups within threads, so
that you could still use the very lightweight Erlang thread
scheduling. AFAIR, the main problem was making the VM
support (efficiently) thread-safe, though.

I think it's interesting to be able to combine multi-CPU
support with many thousand processes. One use that comes to
mind would be to separate communication and control (where
there could be thousands of control threads), or control and
Operation and Maintenance, while still running on the same
processor board. Essentially, coarse-grained load sharing
without many of the hassles of distributed computing
(loosely coupled computers on a slow communication medium.)

/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson Telecom AB, ATM Multiservice Networks