Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Parallelism with threads
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-01-08 (20:55)
From: Jonathan Bryant <jtbryant@v...>
Subject: Re: [Caml-list] Parallelism with threads

On Jan 8, 2008, at 3:43 PM, Brian Hurt wrote:

> Jon Harrop wrote:
>> On Tuesday 08 January 2008 20:00:00 Brian Hurt wrote:
>>> Actually, something that might be nice to see, now that the flat  
>>> page table has been replaced with a heap that can handle disjoint  
>>> heap spaces, is to allow multiple different Ocaml runtimes to be  
>>> running in seperate threads in the same process. The heaps  
>>> wouldn't be able to see each other, but they'd be able to  
>>> communicate via light weight (and strongly typed) message  
>>> passing, and you wouldn't have to dink around with sockets,  
>>> pipes, MPI, or simiar "heavy weight" solutions, so it'd be  
>>> simpler, and possibly faster. This is not unlike the Erlang  
>>> model, in fact.
>> This is exactly the kind of thing I'm interested in!
> I take this back- I've just figured out it wouldn't work.  Global  
> variables would be seen as the same in both threads.  Basically, if  
> you had
>     let foo = ref [ 1; 2; 3 ];;
> then the memory location foo would be seen by code in both  
> runtimes, but the actual list elements would be in one thread and  
> not the other. Worse yet, it's mutable data, so now you've got the  
> possibility of  a list going back and force between threads.  Mass  
> pandemonium breaks out.
> This is a bad idea.

Yes, this is the problem of not having a truly parallel GC.  OTOH,  
what about adding a spawn command (in addition to Thread.create)  
which created a separate instance of the runtime (like you suggested)  
and used copy-on-write semantics for the heap?  You still get the  
benefits of the same process (lightweight message passing, etc) with  
true SMP support but there is no need for a parallel GC since there  
are separate heaps.  There is, of course, still the problem that  
communication channels still need to be shared between heaps somehow...

As far as the Erlang Concurrency project from OSP, I can't say for  
sure but I'm pretty sure that it uses heavyweight processes to  
emmulate Erlang and doesn't modify the runtime.

--Jonathan Bryant

> Brian
> _______________________________________________
> Caml-list mailing list. Subscription management:
> Archives:
> Beginner's list:
> Bug reports: