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