From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 134A5BC57 for ; Tue, 30 Nov 2010 15:22:14 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8BAJOX9EzU4xEIkGdsb2JhbACDUJEDjj0VAQEBAQkJDAcRAx+yU5EhAoEfgzNzBIcQhmE X-IronPort-AV: E=Sophos;i="4.59,280,1288566000"; d="scan'208";a="68857017" Received: from moutng.kundenserver.de ([212.227.17.8]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Nov 2010 15:22:13 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-222-142.pools.arcor-ip.net [94.219.222.142]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MFR0G-1P9C1A26D6-00EhOh; Tue, 30 Nov 2010 15:22:12 +0100 Received: from [192.168.1.111] (84-107-230-64.dsl.quicknet.nl [84.107.230.64]) by office1.lan.sumadev.de (Postfix) with ESMTPA id 2E7185F702; Tue, 30 Nov 2010 15:22:12 +0100 (CET) Subject: Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?) From: Gerd Stolpmann To: Stephan Houben Cc: oliver@first.in-berlin.de, caml-list@yquem.inria.fr In-Reply-To: <4CF50470.802@planet.nl> References: <4CF50470.802@planet.nl> Content-Type: text/plain; charset="UTF-8" Date: Tue, 30 Nov 2010 15:22:10 +0100 Message-ID: <1291126930.16005.578.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:vzS3ZzMXzu0QOJiRGwmeDxottH9lc4o3WAjxdQVxlJ3 TPl75yg0q/ed3iLruQnGDgXZ8rSXJ2681zhJ3rpsVvUmXvJijQ JMhc1GH2R8NttVrzBaF1pT17chvccXrltgJW+qTxdhSJt2e51Q toM0krQVlPO4o+F0bgll2wI2+nED1h9sBBWhOf59sLqleJtS/J zJ/0SW+ZtFml8555hhiDg== X-Spam: no; 0.00; threading:01 ocaml:01 gerd:01 stolpmann:01 in-berlin:01 bigarray:01 inherently:01 bigarray:01 ocaml:01 corresponds:01 byte:01 corresponds:01 byte:01 waitpid:01 threading:01 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 ------------------------------------------------------------