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

[Philippe Wang <Philippe.Wang@lip6.fr>]

> Le 14 avr. 09 à 12:21, Philippe Wang a écrit :
>
>>     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 ?

No, it isn't. (And it would probably too often prevent parallel  
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  
more parameter than "before") (e.g. in amd64.S)

Philippe Wang