English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
"ok with parallel threads" GC (aka ocaml for multicore)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-04-16 (09:45)
From: Philippe Wang <Philippe.Wang@l...>
Subject: Re: [Caml-list] "ok with parallel threads" GC (aka ocaml for multicore)
> 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