Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Complex Numbers
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
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