On Monday 25 January 2010 15:46:10 Hubert Matthews wrote:
> Processes in Erlang are very lightweight. A process uses about 300 bytes
> of memory instead of 1 megabyte for most thread implementations. They are
> also much quicker to create, destroy and switch between. Lightweight
> processes are in effect "green threads" and are multiplexed evenly across
> multiple CPUs. Some Erlang examples have shown a scaleup factor of 28 on
> 32 CPU machines.
>
> Pthreads are larger and heavier than Erlang processes. They contain state
> that makes them harder to migrate between CPUs efficiently. Threaded
> applications are either compute bound or I/O bound. Compute limited apps
> will scale well using OpenMP or thread pools (or preferably a library such
> as Intel's Threading Building Blocks). I/O limited applications with
> threads will, however, end up using a lot of threads for blocking I/O and
> this limits their scalability in comparison to Erlang's integrated
> messaging. Erlang also has cross-machine distribution built in and it's
> easy because it has no shared state.
So Erlang has no notion of threads, just lightweight processes. What I have
not been able to understand from your explanation is how Erlang processes are
mapped to operating system native scheduling entities, e.g. kernel threads.
Are Erlang processes similar to user level threads, i.e. if a Unix process
blocks, all user level threads in that process are also blocked.
You also mention that Erlang has no shared state and achieves parallel
processing by message passing. But surely you can't completely avoid shared
objects? If you have a single counter, how do Erlang processes manage to
update the counter?
(text/plain)