Getting locks and sharing: was RE: Getting concurrency
Tue Jul 5 12:51:24 CEST 2005
--- Reto Kramer <> wrote:
> I find it very unnatural to have to conceive of
> multiple nodes per
> machine "just" because there's no VM technology in
> Erlang that takes
> advantage of multi-CPU machines _transparently_.
Note that an approach of using multiple sequential
nodes instead of a multithreaded node could be fairly
transparent to the programmer, with the appropriate
Also note that it's not clear how transparent the
issues of parallelism _should_ be, in either approach.
> Where can I learn about what's been done in the past
> and get a sense of
> the Erlang specific challenges and the complexity of
> such a multi CPU
> aware VM?
Have a look at Pekka's MSc, or dig your way through
the endless ranks of papers on implicit
parallelization from the 80s to the early 90s :-)
I'd say the first issue for a multithreaded VM is to
make the runtime system thread safe (and robust). The
second issue is to make it scalable. The third issue
is to make it competitive with a sequential VM.
(And somewhere in that list, we can begin worrying
about how well our whole erlang systems perform :-)
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
More information about the erlang-questions