[MLton] Ongoing parallel runtime work

[Eric McCorkle]

On Jan 22, 2008, at 6:02 PM, Matthew Fluet wrote:
> Under the current runtime, much of the thread code is implemented  
> in SML. What does it mean that 'the thread code is all external'?
>

The scheduler I wrote is entirely in C.  It provides M:N scheduling  
using completely lock-free algorithms (the ultimate aim is to combine  
this with GC-allocated frames and other mechanisms with the hope of  
bringing thread-creation overhead down to some small multiple of a  
function call)  The threading library on the SML side will be mostly  
a wrapper.

There's two reasons for this being written in C:

1) With a parallel garbage collector, you have to invoke the  
scheduler to run the collector, which ends up creating problems if  
the scheduler allocates from the collector.  There are ways around  
this, but they get nasty, and...

2) It's easier to make the scheduler system completely free of locks  
this way.  Aside from scaling to large numbers of processors, doing  
this has the benefit of being able to freely create threads in an  
asynchronous context, et cetera.

> Testing with MLton-compiled SML programs or testing with a  
> scheduler specific harness?

I have an artificial program which randomly creates and destroys  
threads.

> I know that your project has been a "standalone runtime for  
> concurrent functional languages", with the hope that it could serve  
> as an alternate runtime for MLton.  I'm simply curious about the  
> extent to which it has actually been integrated with MLton (or  
> MLton integrated with it).

I'll be integrating once I finish the collector itself.  I'll  
probably also write a simple random test program for the collector  
and the malloc implementation.  I'm aiming to start some of the  
integration next week, when the collector is mostly written.

-- 
Eric McCorkle
Brown University
CS Graduate Student


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20080122/2504962a/attachment.html