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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id DE2E1BC57 for ; Mon, 29 Nov 2010 17:24:52 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMBAG9i80zU436rkGdsb2JhbACDUJB7jjgVAQEBAQkJDAcRAx+yNpBRAoEfgzNzBIcQhmA X-IronPort-AV: E=Sophos;i="4.59,276,1288566000"; d="scan'208";a="81336910" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail2-smtp-roc.national.inria.fr with ESMTP; 29 Nov 2010 17:24:52 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-212-163.pools.arcor-ip.net [94.219.212.163]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MB15o-1PFRZH0HWW-009vjs; Mon, 29 Nov 2010 17:24:43 +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 A22515F702; Mon, 29 Nov 2010 17:24:42 +0100 (CET) Subject: Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?) From: Gerd Stolpmann To: Oliver Bandel Cc: caml-list@yquem.inria.fr In-Reply-To: <20101129171212.8439157ahjexnnq4@webmail.in-berlin.de> References: <20101123232742.GC28768@siouxsie> <1534555381.33107.1290723160355.JavaMail.root@zmbs4.inria.fr> <4CEEE852.5070101@inria.fr> <20101128181433.GA1689@siouxsie> <1291040394.16005.529.camel@thinkpad> <20101129171212.8439157ahjexnnq4@webmail.in-berlin.de> Content-Type: text/plain; charset="UTF-8" Date: Mon, 29 Nov 2010 17:24:40 +0100 Message-ID: <1291047880.16005.533.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:o6HH4sR374QGxzgPTpDsQsWPV6+W64IPJz8VnAIbMDj gmSlUQwCsx3bkfu9Iu78IqxuH6cg8dPf1dZj5ypFFJ7Q/YA7sn D5fGqus7BLfx3Ys5zNEnOhPTDiGkcnIfBTkvMwTCKHJsjKP8o1 sWw1S62S++iwaQFPvHYPM5DtzdJXwhNAT83YxS8FhuggJMaz0j YH+/xxUYjqZsHoOOmT9Og== X-Spam: no; 0.00; threading:01 ocaml:01 gerd:01 stolpmann:01 bandel:01 gerd:01 stolpmann:01 in-berlin:01 0100,:01 ocaml:01 compiler:01 low-level:01 libs:01 beginner's:01 bug:01 Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel: > Zitat von "Gerd Stolpmann" : > > > Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb > > oliver@first.in-berlin.de: > >> On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote: > >> [...] > >> > The main problem was that other languages have bigger standard > >> > libraries, whereas OCaml has a very small one (just what is needed > >> > to compile the compiler, actually). In many problems, you could > >> > benefit from using a very simple shared-memory library (in > >> > mandelbrot, the ocaml multicore solution has to copy the image in a > >> > socket between processes, whereas it could just be in a shared > >> > memory segment), > >> > >> > >> ...so you work on a shared-mem module?! > > > > Don't know what Fabrice is referring to, but at least I work on a > > multicore-enabling library: > > > > https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netmulticore/ > > > > This is work in progress and highly experimental. What's currently > > available: > > > > - managing processes and resources like files, shared memory objects > > etc. > > - support for message passing via Netcamlbox (another library) > > - low-level only so far: shared memory, including copying Ocaml values > > to and from shm > [...] > > You use shared mem(?), but you link only to *.ml files, > and I see no *.c there. cd ../netsys it's part of a larger package > > How can this be done? > > At least not via the libs that are shipped with OCaml?! > > I would have expected some *.c for the shared mem part and > the creation of Caml-values.... > > > Ciao, > Oliver > > P.S.: OCaml also provides a Thread-Lib, which seems to use pthread-lib. > Normally this should help in making things possible to run on multiple > cores. What are the restrictions that this does not run that way? > Somehow... when all values are handled via one GC, then those threads > are somehow bound together, but on the other side, it works threaded, > and consumer-worker pipes and such stuff can be used. > So... somehow the GC seems to be the point, where the show will be > stopped? (Anyone who has looked inside OCaml here more detailed?) Quite easy: there is a global lock, and when Ocaml code runs, this lock must be acquired. So only one of the pthreads can have this lock, and so only one pthread can run Ocaml code. The reason is that memory management is not thread-safe. Gerd > > _______________________________________________ > 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 ------------------------------------------------------------