From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p2PC83eL011901 for ; Fri, 25 Mar 2011 13:08:03 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArICABGFjE3U4366kGdsb2JhbACEQ6EQFAEBAgkJDQcUJYhNqjKRJAKBJYNLdwSIL4ga X-IronPort-AV: E=Sophos;i="4.63,242,1299452400"; d="scan'208";a="91121743" Received: from moutng.kundenserver.de ([212.227.126.186]) by mail4-smtp-sop.national.inria.fr with ESMTP; 25 Mar 2011 13:07:58 +0100 Received: from office1.lan.sumadev.de (dslb-188-097-077-012.pools.arcor-ip.net [188.97.77.12]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MGDrv-1QG46c1hEl-00FMwd; Fri, 25 Mar 2011 13:07:57 +0100 Received: from [192.168.1.111] (546BE640.cm-12-4d.dynamic.ziggo.nl [84.107.230.64]) by office1.lan.sumadev.de (Postfix) with ESMTPA id 002C75F701; Fri, 25 Mar 2011 13:07:56 +0100 (CET) From: Gerd Stolpmann To: Fabrice Le Fessant Cc: Alain Frisch , caml-list@inria.fr In-Reply-To: <4D8C6D10.2020205@inria.fr> References: <2054357367.219171.1300974318806.JavaMail.root@zmbs4.inria.fr> <4D8BD02D.1010505@inria.fr> <1396338209.232813.1301046980856.JavaMail.root@zmbs4.inria.fr> <4D8C6D10.2020205@inria.fr> Content-Type: text/plain; charset="UTF-8" Date: Fri, 25 Mar 2011 13:07:55 +0100 Message-ID: <1301054875.8429.298.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:6cHMxo6QC6/CeBb6vgTk5yQ9Y8EtcxZYqlGyPUxvCsO NRMbNGX6cXeLTkxaLNl7+FfRci1WY9F+g/z60pplETS85eWxQv T88wO6dfR7Pq0uVy6pnb3YgRcHFuZCqbZMNsSxYw6zIO0jJGjs rwjjEWh9WyIwJgh4eLlJU/zK6LxDKLqtL9/2MW0h5W7aILVmsf A9I2fdgzY3pCZMF39xjhQ== Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap? > For the FFI, I think it is actually possible to keep some > backward-compatibility, by allowing both a new kind of external C > functions (taking a thread specific context as argument, and declared > with the "reentrant" flag introduced by Sylvain) and the former kind > (without the context). Each function of the runtime would come in both > kinds, for example "caml_alloc_r" taking the context as extra argument, > and "caml_alloc" without the context, the latter being a wrapper for > the former, with a way to recover the context in the middle (either > through TLS or thread specific). Most stub libraries would probably work > without change, maybe with a little extra-cost (actually, I think TLS is > costless, and thread specific is very efficient on Mac OS X where TLS > does not exist). AFAIK TLS is not costless but relatively cheap. There is an extra indirection for each access (as if the variables were arrays indexed by a thread ID). The thread ID is stored in otherwise unused registers that are left-overs from the 16 bit times. I guess there could be some performance impact on frequently accessed GC variables (e.g. caml_young_limit). > > One advantage of the approach you describe is that it would allow to use > > native libraries that support multi-threading. Do you see other advantages? > > As I said before, the main one for me is the ability to setup everything > in one process, you can for example create locks, shared segments and > other synchronisation primitives in the main thread, before creating the > other threads, which is a little more difficult with multi-processing. I think the more interesting point is that you create/setup the primitives after creating the threads, and this is very easy because of the shared address space. There are POSIX calls for doing this in the multi-process approach but the remaining problem is that one cannot control the address space, especially that shared memory is mapped to the same address in all processes. Gerd > > Cheers, > -- > Fabrice > -- ------------------------------------------------------------ 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 ------------------------------------------------------------