From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 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 875B8BBC4 for ; Thu, 16 Apr 2009 11:45:41 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgDAHOb5kmE4zwCgWdsb2JhbACWJAEBFiK6G4N9Bg X-IronPort-AV: E=Sophos;i="4.40,197,1238968800"; d="scan'208";a="26339008" Received: from isis.lip6.fr ([132.227.60.2]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Apr 2009 11:45:37 +0200 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.13.5.20060614/lip6) with ESMTP id n3G9jaql015344 for ; Thu, 16 Apr 2009 11:45:36 +0200 (CEST) X-pt: isis.lip6.fr Received: from [192.168.2.27] (micmac [132.227.83.124]) by tibre.lip6.fr (8.13.5.20060614/8.13.3) with ESMTP id n3G9javD006308 for ; Thu, 16 Apr 2009 11:45:36 +0200 (MEST) Message-Id: <9E5A9BDB-2A67-45DC-A963-AA45B7E1693B@lip6.fr> From: Philippe Wang To: caml-list@inria.fr In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [Caml-list] "ok with parallel threads" GC (aka ocaml for multicore) Date: Thu, 16 Apr 2009 11:45:32 +0200 References: <50CD0BA8-B89C-49E2-9082-FFA037F251A6@lip6.fr> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (isis.lip6.fr [132.227.60.2]); Thu, 16 Apr 2009 11:45:36 +0200 (CEST) X-Scanned-By: MIMEDefang 2.63 on 132.227.60.2 X-Spam: no; 0.00; ocaml:01 runtime:01 patched:01 ocamlopt:01 runtime:01 patched:01 ocaml:01 byterun:01 threads:01 threads:01 garbage:01 caml-list:01 functions:01 functions:01 reentrant:02 > Le 14 avr. 09 =E0 12:21, Philippe Wang a =E9crit : > >> The garbage collector is clearly separated from the rest of the =20= >> runtime library: the GC is contained in a libgc.a and our patched =20 >> ocamlopt links programs to this GC. The GC variables are known by =20 >> the GC only. > > Well, this is not what I had in mind, but I realize that my question > was not clear. A better question would have been: > Is your implementation still based on a global runtime lock ? No, it isn't. (And it would probably too often prevent parallel =20 threads, wouldn't it.) > A negative answer would imply that you patched the OCaml > runtime to make it reentrant. To illustrate my point, I will take > the example of the file "byterun/compare.c". In this file, the > code for the comparison of values makes use of a global > variable (named "caml_compare_unordered"). It should be, unless bugs are still hiding under that. It is supposed to have been done for a while. We'll make one more check. > If you patched the runtime to allow multiple threads to use > it concurrently, I would also be interested by the strategy > used: is the problem solved by additional parameters ? > by the use of thread-local storage ? by any other mean ? - local variable instead of global variable in functions - some functions are parameterized by thread identifier (that is, one =20= more parameter than "before") (e.g. in amd64.S) Philippe Wang=