Re: [Caml-list] Efficient OCaml multicore -- roadmap?

[Gerd Stolpmann <info@gerd-stolpmann.de>]

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