From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA26415 for caml-redistribution; Tue, 2 Sep 1997 10:24:38 +0200 (MET DST)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA14318 for <caml-list@pauillac.inria.fr>; Mon, 1 Sep 1997 17:24:12 +0200 (MET DST)
Received: from pauillac.inria.fr ([128.93.11.35])
	by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id RAA09106;
	Mon, 1 Sep 1997 17:24:10 +0200 (MET DST)
Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA14310; Mon, 1 Sep 1997 17:24:09 +0200 (MET DST)
From: Xavier Leroy <Xavier.Leroy@inria.fr>
Message-Id: <199709011524.RAA14310@pauillac.inria.fr>
Subject: Re: Thread library for ocamlopt?
In-Reply-To: <9708291801.AA05339@crunch> from Thorsten Ohl at "Aug 29, 97 08:01:22 pm"
To: ohl@crunch.ikp.physik.th-darmstadt.de (Thorsten Ohl)
Date: Mon, 1 Sep 1997 17:24:08 +0200 (MET DST)
Cc: caml-list@inria.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: weis

> > * 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