Re: Thread library for ocamlopt?

[Xavier Leroy <Xavier.Leroy@inria.fr>]

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