Re: [Caml-list] "ok with parallel threads" GC (aka ocaml for multicore)

[xclerc <xavier.clerc@inria.fr>]

Le 14 avr. 09 à 12:21, Philippe Wang a écrit :

> On Apr 10, 2009, at 20:36 CEDT, forum@x9c.fr wrote:
>
>> Would it be correct to assume that the current state of the project
>> implies that you have patched the OCaml runtime to make it
>> fully reentrant ?
>
> Is this following partial answer relevant enough ?
> The garbage collector is clearly separated from the rest of the  
> runtime library: the GC is contained in a libgc.a and our patched  
> ocamlopt links programs to this GC. The GC variables are known by  
> 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 ?

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").

So, allowing multiple threads to execute primitives from the
runtime at the same time may result in incorrect outcomes.
Unless you patch the runtime to make it reentrant, hence my
original (foolishly indirect) question.

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 ?


Xavier Clerc