Browse thread
Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2010-11-30 (12:55) |
From: | oliver@f... |
Subject: | Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?) |
On Tue, Nov 30, 2010 at 09:10:36AM +0100, Stephan Houben wrote: > On 11/29/2010 04:33 PM, Oliver Bandel wrote: > >Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>: > > > >>Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel: > >>>Zitat von "Gerd Stolpmann" <info@gerd-stolpmann.de>: > >>> > > >>>You use shared mem(?), but you link only to *.ml files, > >>>and I see no *.c there. > > >>>How can this be done? > >>> > >>>At least not via the libs that are shipped with OCaml?! > > Actually it can be done using the libs that ship with OCaml > (Unix and Bigarray), although it is not 100% POSIX : > > let create_shared_genarray kind layout dims = > let fd = Unix.openfile "/dev/zero" [Unix.O_RDWR] 0 > in let ar = Bigarray.Genarray.map_file fd kind layout true dims > in Unix.close fd; ar > > > The resulting bigarray object is shared among subsequent forks. Hmhhh... we started talking about Threads and SharedMem. You mean even fork.... hmhhh > This relies on the fact that mmap-ing /dev/zero is equivalent > to an anonymous mmap. > > http://en.wikipedia.org/wiki//dev/zero > > Well, at least it works on Linux. In APUE it's mentioned that memory mapped regions are inherited by a child, when forking it. So it should work on all Unix-systems too. 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... ..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. 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... (A thread-specific GC for thread-specific variables would help here, making global locks only necessary when accessing global used variables. But I don't know if such a way would be possible without changing the GC-stuff itself.) Ciao, Oliver