Re: threads library in Objective Caml

From: Francois Rouaix (Francois.Rouaix@inria.fr)
Date: Mon Apr 14 1997 - 19:06:41 MET DST


Message-Id: <199704141706.TAA17965@madiran.inria.fr>
From: Francois Rouaix <Francois.Rouaix@inria.fr>
To: Pawel Wojciechowski <Pawel.Wojciechowski@cl.cam.ac.uk>
Subject: Re: threads library in Objective Caml
Date: Mon, 14 Apr 1997 19:06:41 +0200

> The potential advantage of threads is that on a multiprocessor shared memory
> machine, each thread can run on a different processor.
Also, even on a single processor, threads are useful for highly IO/network
dependant programs (such as web tools and distributed computation). That's
where we have used them mostly.

> Assuming that the threads library of the (O)Caml is implemented by using
> the POSIX Unix thread library, in the light of the previous paragraph, it
> seems to me that using threads in programs written purely in Caml is less
> powerful (in terms of the program behaviour on multi-processor architecures)
> that using threads in a program written in C. Could you briefly explain
> this ?
There are two different implementations. One (the threads library), usually
called bytecode threads, doesn't use Posix threads at all. It's user-level
threads, taking advantage of the bytecode approach (but also with its assorted
limitations). It's only real use is for IO-bound programs (e.g. my V6 web
proxy, or web crawler).

The other implementation (otherlibs/systhreads) relies on Posix
(preferably kernel) threads. I'll quote a previous answer of Xavier on
that same topic (since he's away for some time):

XL> The good news is that OCaml already has support for native threads
XL> (as opposed to bytecode-level threads), both for Win32 and for POSIX
XL> threads. Look in the otherlibs/systhreads subdirectory. We don't
XL> advertise the POSIX binding because so few Unix actually implement
XL> POSIX 1003.1b, but it's there.

XL> The bad news is that most of the OCaml runtime is still not
XL> thread-ready, in particular the memory manager, so we have to put a
XL> big critical section around the whole bytecode interpreter and GC.
XL> What this means is that at any time, at most one thread can be
XL> executing Caml code, or allocating, or garbage collecting. Other
XL> threads are either stopped or executing foreign (non-Caml) code.

XL> As you can see, this is a very quick hack, but it works relatively
XL> well for the kind of applications we're interested in: asynchronous I/
XL> O in several threads. In this case, most threads are blocked most of
XL> the time on I/O calls, so the global mutual exclusion does not harm
XL> parallelism too much.

XL> Of course, it's a terrible idea for doing intensive computations on a
XL> multiprocessor. Essentially, this scheme prevents you from taking
XL> advantage of more than one processor!

XL> We did some work on a truly concurrent garbage collector and runtime
XL> system for Caml Light, back into 1991-1992. This eventually became
XL> Damien Doligez's PhD thesis (see
XL> http://pauillac.inria.fr/~doligez/caml-light-gc/
XL> for the full story).

XL> Damien's design was (and still is) very nice, but to my great regrets
XL> he did not bring his implementation to completion.

Finally,
> On the other hand, on a single processor architecture, programs
> written in Caml or C should take advantage of using threads library
> in exactly the same way. Am I right?
I guess so. Except that bytecode threads are essentially portable, even
if you don't have Posix threads available.

--f



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:10 MET