Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)

[Eray Ozkural <examachine@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

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
> 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

[-- Attachment #2: Type: text/html, Size: 2329 bytes --]