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 A3D69BC57 for ; Tue, 30 Nov 2010 16:17:23 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjECAHek9EzRVdU0k2dsb2JhbACUVYYrAYc2UwgVAQEBAQkJCgkRAx+pQ4lkghiFRS6IVgEBAwWFQgSKYg X-IronPort-AV: E=Sophos;i="4.59,280,1288566000"; d="scan'208";a="68862124" Received: from mail-yw0-f52.google.com ([209.85.213.52]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Nov 2010 16:17:22 +0100 Received: by ywf9 with SMTP id 9so2716171ywf.39 for ; Tue, 30 Nov 2010 07:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=IoAqYB753oUXU6lunGs1LoVlD/8gXgI+/5GQAqJmOdE=; b=eW+ifdPiIGKq36ILERc4f33+nLaCLkgmLY+MUrgPytbIWx6WsWETFUOuWbOMO07YDa CE0TEvHP2YJC7B9+cmipeCK5s4ZHi9nb5h4n+/QEXdP1cYDFfQ0PSh2l7k4buAcLoX+c jgOHWGHU8P2eYILYmuuNn0tFummyobx1xsNvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XX80MW3Zu++gRyxbpCapHH8mS0JW1HbbWEuqhOj2tpkwXpreMuNiLdLiXQEtjHUndE DRZYty9/cO09TJe1LJImJCgL251lX5j0wSnvbV8MCd52dKe9f6Jgwbjbt5KYggJlA5ef XE70snHHPrrCX1gLvmpoCwWVcrLdNQKCDnbNs= MIME-Version: 1.0 Received: by 10.90.87.9 with SMTP id k9mr11214030agb.150.1291130241845; Tue, 30 Nov 2010 07:17:21 -0800 (PST) Received: by 10.90.211.10 with HTTP; Tue, 30 Nov 2010 07:17:21 -0800 (PST) In-Reply-To: <20101130142941.GG1637@siouxsie> References: <4CF50470.802@planet.nl> <20101130142941.GG1637@siouxsie> Date: Tue, 30 Nov 2010 17:17:21 +0200 Message-ID: Subject: Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?) From: Eray Ozkural To: oliver@first.in-berlin.de Cc: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=0016361e88a66c88fb049646afec X-Spam: no; 0.00; threading:01 ocaml:01 eray:01 ozkural:01 in-berlin:01 ocaml:01 compiler:01 runtime:01 runtime:01 vars:01 substituted:01 alloc:01 malloc:01 eray:01 ozkural:01 --0016361e88a66c88fb049646afec Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 30, 2010 at 4:29 PM, wrote: > > And here I see a thread-specific GC as a solution. > > It seems to me that this way was not thought about before, > and people thought about changing the GC to be able to handle multiple > threads. > Instead I mean: each thread that is not the global thread, get's it's own > thread-specific GC. > > Maybe that can be implemented much easier. > But I've not looked into the Ocaml internals to say: yes, this can be done > comparingly easy, or to say: oh no, that's more complex than changing the > GC and make it > handle all the threads from the main thread. > > I just would assume that seperate threads would be easier to handle. > > But maybe there are other restrictions in the language or the compiler > that block this attempt. > > Not anything that I have yet found but I am curious about the opinion of the runtime designers as well. There seem to be some global variables in the runtime, which isn't the best way to write it anyway, if all vars are local then it becomes easier to embed, thread and fork as you like. That is to say, such a level of virtualization allows the global lock to be substituted with whatever locking the system alloc functions have, i.e. when many malloc requests overlap. Except that, the user has to explicitly sync his mem accesses so I don't think there could be any problem. And no other part of the library is thread-safe either (which is great for performance!). So I think each thread can have its own GC. Perhaps there is an obstacle I have not yet noticed? Best, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct --0016361e88a66c88fb049646afec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 30, 2010 at 4:29 PM, <oliver@first.in-berlin= .de> wrote:
And here I see a thread-specific GC as a solution.

It seems to me that this way was not thought about before,
and people thought about changing the GC to be able to handle multiple thre= ads.
Instead I mean: each thread that is not the global thread, get's it'= ;s own
thread-specific GC.

Maybe that can be implemented much easier.
But I've not looked into the Ocaml internals to say: yes, this can be d= one
comparingly easy, or to say: oh no, that's more complex than changing t= he GC and make it
handle all the threads from the main thread.

I just would assume that seperate threads would be easier to handle.

But maybe there are other restrictions in the language or the compiler
that block this attempt.


Not anything t= hat I have yet found but I am curious about the opinion of the runtime desi= gners as well. There seem to be some global variables in the runtime, which= isn't the best way to write it anyway, if all vars are local then it b= ecomes easier to embed, thread and fork as you like. That is to say, such a= level of virtualization allows the global lock to be substituted with what= ever locking the system alloc functions have, i.e. when many malloc request= s overlap.

Except that, the user has to explicitly sync his mem ac= cesses so I don't think there could be any problem. And no other part o= f the library is thread-safe either (which is great for performance!). So I= think each thread can have its own GC. Perhaps there is an obstacle I have= not yet noticed?

Best,

--
Eray Ozkural, PhD candidate= .=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosop= hy
http://myspace.com/arizanesil= http://myspace.com/malfunct
--0016361e88a66c88fb049646afec--