Browse thread
"ok with parallel threads" GC (aka ocaml for multicore)
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2009-04-14 (14:18) |
From: | xclerc <xavier.clerc@i...> |
Subject: | Re: [Caml-list] "ok with parallel threads" GC (aka ocaml for multicore) |
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