From: Jonathan Bryant <jtbryant@valdosta.edu>
To: Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] Parallelism with threads
Date: Tue, 08 Jan 2008 15:55:24 -0500 [thread overview]
Message-ID: <D5DB9831-A81A-416A-BAA2-069003DD963D@valdosta.edu> (raw)
In-Reply-To: <4783E08D.6040007@janestcapital.com>
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:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
next prev parent reply other threads:[~2008-01-08 20:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 14:56 Jon Harrop
2008-01-08 19:31 ` [Caml-list] " Daniel Andor
2008-01-08 20:00 ` Brian Hurt
2008-01-08 20:19 ` David MENTRE
2008-01-08 20:23 ` Jon Harrop
2008-01-08 20:43 ` Brian Hurt
2008-01-08 20:55 ` Jonathan Bryant [this message]
2008-01-08 23:47 ` Benedikt Grundmann
2008-01-09 14:46 ` Daniel Andor
2008-01-09 16:04 ` Richard Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D5DB9831-A81A-416A-BAA2-069003DD963D@valdosta.edu \
--to=jtbryant@valdosta.edu \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox