Re: Thread library for ocamlopt?

From: Xavier Leroy (
Date: Mon Sep 01 1997 - 17:24:08 MET DST

From: Xavier Leroy <>
Message-Id: <>
Subject: Re: Thread library for ocamlopt?
In-Reply-To: <9708291801.AA05339@crunch> from Thorsten Ohl at "Aug 29, 97 08:01:22 pm"
To: (Thorsten Ohl)
Date: Mon, 1 Sep 1997 17:24:08 +0200 (MET DST)

> > * Available only on Unix systems that provide fully conformant
> > Posix 1003.1c threads, e.g. Solaris 2.5, Digital Unix 4.0, or
> > Linux with LinuxThreads, but not HPUX, SunOS, nor earlier
> > versions of Digital Unix, for instance.
> Couldn't the implementation on the latter three OSs emulate the
> semantics (without the performance benefit, of course) with the old
> threads?

The two thread libraries (the bytecode-level one and the one built on
top of Posix threads) have the same API and (hopefully) the same
semantics, so, as you say, the bytecode-level library can still be
used as a fallback solution on operating systems that do not provide
Posix threads.

> Then programs would remain portable and users of
> multiprocessor machines running the former three OSs could start
> chasing around the FORTRAN crowd :-).

The only remaining problem is that the OCaml code is still essentially
single-threaded -- by lack of a suitable GC, we can't have more than
one thread executing Caml code at any given time. So, the Caml code
can't exploit a multiprocessor. I/O operations and code written in C
can still run concurrently with the Caml code, though.

Overall, the Caml thread libraries won't make your code run faster;
they are mainly useful to facilitate overlapping I/O and other forms
of asynchronous communications.

> > * Preemption of long-running threads can only occur at
> > allocation points (for reasons relevant to both the garbage
> > collector and the handling of signals in ocamlopt), which can
> > result in a relatively rough scheduling for compute-bound
> > threads.
> By your high standards it will be considered a nasty hack, but what
> will prevent us users from adding spurious allocation points, if the
> scheduling turns out to be too rough in a practical case?

You can do that, of course. Most Caml code already allocates often
enough so that it's not necessary.

Another way to explicitly give other threads a chance to run is to
call Thread.yield().

Finally, most I/O and thread synchronization operations (Mutex.lock,
etc) are also rescheduling points.

- Xavier Leroy

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