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: | -- (:) |
| 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