[MLton] Multicore CPU's and MLton

Matthias Kretschmer mccratch@gmx.net
Wed, 06 Jul 2005 20:35:43 +0200


Stephen Weeks wrote:

>>In Erlang (http://www.erlang.org), parallelism is modeled as
>>separate processes communicating through message passing.  While
>>message passing is obviously not as cheap as shared memory, it has
>>the advantage of completely isolating separate threads of execution
>>such that failure in one does not cause failure in another.
>>    
>>
>
>I don't know enough about the Erlang implementation.  I wonder if they
>support concurrent threads.  They're surely not using an OS process
>for each thread.
>
>  
>
(open source erlang:) As far as I know at least the standard 
installation (if you just issue ./configure) doesn't use OS level 
threads. They provide very lightweight threads in the sense that their 
runtime system is handling them, except that you don't have to provide a 
scheduling mechanism (and I am not aware of any method of doing manual 
scheduling). But for the memory management part there are three basic 
models (in R10B only two are "supported" out of the box): private heaps 
and hubrid model. In previous versions a share heap model was supported.

private heap just gives each process its own heap allowing the garbage 
collector to run for a single thread without the need of locking the 
other threads. The drawback is of course that any message has to copy 
data from one private heap to another. On the other hand without any 
hassles or global locks a copying garbage collector can be used. There 
is one exception for this: binaries are placed in a shared heap even in 
the private heap model (standard model for years). Shared heap is as the 
name says: the heap is shared. The drawback is of course that copying 
garbage collection would really block the whole system. As far as I know 
there are garbage collectors that are able to work with shared heaps 
without a global lock, but I have not much clue about garbage collector 
techniques. The hybrid model is quite new (and if I recall correctly 
experimental). It merges the other two models: there exists a private 
heap and a shared heap. There is some paper available (from the people 
making Dialyzer and HiPE I think). The idea is that with the help of the 
compiler (that was not available at the time the paper was written) it 
can be decided partly if data will be send to other processes and then 
will be put from the beginning into the shared heap. If data is in the 
private heap and send to another processes it is not copied to the 
private heap of the other processes, but to the shared heap (so if you 
send the same information multiple times, you're lucky that you just 
have to move a pointer around, after the first copy). Erlang does not 
support mutable data (except for special data tables), so there is no 
problem. The situation is of course not so simple if the language 
provides facilities like ref-cells.

--
Matthias Kretschmer