Browse thread
[Caml-list] Complex Numbers
[
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: | 2001-04-02 (13:27) |
From: | Xavier Leroy <Xavier.Leroy@i...> |
Subject: | Re: [Caml-list] Threads in OCaml |
> [OCaml's "master lock"] > How good or bad an arrangement is this? I've been asked about the > threading facilities of ocaml, but I don't know enough to compare and > contrast, say, ocaml and Java. On a multiprocessor machine, the "master lock" scheme is really bad, since it prevents OCaml code from running on more than one processor at once. On a single-processor machine, it's OK, but not great. Since there is only one processor, it's not that bad to serialize execution of all OCaml code -- execution of all threads is eventually serialized on the processor. However, the extra locking performed at the level of the OCaml code can make thread scheduling a bit less smooth. This depends a lot on the fairness characteristics of the underlying system threads library. As compared with Java, threads in OCaml are a late addition to the library and implementation, while the Java language, libraries and implementations were designed from the very beginning with threads. So one can expect Java threading to be somehow more mature; it is certainly true for the libraries, not so true for the implementations (e.g. Sun's JDK implementation sucks, w.r.t. threads as well as w.r.t. everything else :-). On the other hand, a thread-aware runtime system and library such as Java's pays a significant execution penalty for single-threaded code. In a way, you're paying all the time for hypothetical speedups on less-and-less-common multiprocessor machines. I'll let you decide if this is a reasonable deal or not... - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr