Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Stephan Houben <stephanh@planet.nl>
Cc: oliver@first.in-berlin.de, caml-list@yquem.inria.fr
Subject: Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)
Date: Tue, 30 Nov 2010 15:22:10 +0100	[thread overview]
Message-ID: <1291126930.16005.578.camel@thinkpad> (raw)
In-Reply-To: <4CF50470.802@planet.nl>

Am Dienstag, den 30.11.2010, 15:04 +0100 schrieb Stephan Houben:
> On 11/30/2010 12:55 PM, oliver@first.in-berlin.de wrote:
> > There is one problem with this... when you have forked, then
> > you obviously have separated processes and also in each process
> > your own ocaml-program with it's own GC running...
> 
> ...neatly sidestepping the problem that the GC needs to lock out all threads...
> 
> > .with such a mem-mapping trick (never used Bigarray, so I'm astouned it uses
> > mmap) you then have independent processes, working on shared mem without
> > synchronisation.
> 
> > This is a good possibility to get corrupted data, and therefore unreliable behaviour.
> 
> Well, not more possibility than inherently in any code that updates a shared data structure
> in parallel. It is certainly not the case that the independently executing GCs in both
> processes are causing data corruption, since the GC only operates on unshared memory.
> Note that the GC doesn't move the Bigarray data around.
> 
> (I am not sure if this was in particular your worry or that it was just the lack of
>   synchronisation mechanisms which you bring up next.
>   Apologies if I am addressing some non-concern.)
> 
> > So, you have somehow to create a way of communicating of these processes.
> >
> > This already is easily done in the Threads-module, because synchronisation
> > mechanisms are bound there to the OCaml API and can be used easily.
> >
> > In the Unix module there is not much of ths IPC stuff...
> 
> In fact there is the Unix.pipe function which can be used for message passing
> communication between processes.
> A pipe can also be used as a semaphore:
> operation V corresponds to writing a byte to the pipe, operation P corresponds to reading a byte.
> It's a bit heavy since it always makes a kernel call even for the non-contended case, but
> otherwise it works perfectly.
> 
> For many purposes (e.g. something "embarrassingly parallel" like computing the Mandelbrot set)
> you can just divide the work up-front and only rely on the implicit synchronization given
> by waitpid.
> 
> If you allow me a final observation/rant: I personally feel that the use of fork() and
> pipes as a way to exploit multiple CPUs is underrated. When appropriate (lots of computation
> and not so much synchronisation/communication) it works really great and is very robust because
> all data is process-private by default, as opposed to threading, where everything is shared
> and you have to stand on your head to get a thread-local variable. Performance can also be better
> since you don't run into cache coherency issues.
> 
> I am not sure why it is not used more; possibly because it is not supported on Windows.

I don't think this is the reason. Many people can ignore Windows,
actually.

The problem is more that your whole program needs then to be
restructured - multi-processing implies a process model (which is the
master, which are the workers). With multi-threading you can start
threads at all times without having to worry about that (i.e. supports
"programming without design" if you want to take that as a negative
point).

This is what I want to fix with my Netmulticore library - it defines a
framework allowing you to start new processes at any time without having
to worry about the process hierarchy.

Also, many practical problems are only O(n log n), at most. The cost for
serialization of data through a pipe cannot be neglected here. This
makes shared memory attractive, even if it is only available in a
restricted form (like write once memory).

Gerd

> Stephan
> 
> _______________________________________________
> 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
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------