Thread library for ocamlopt?

Thread library for ocamlopt?

[Ken Wakita]

Hi,

Is there a plan to include the Thread module in the native compiler
framework?  Or is there a work done with native concurrent ocaml?

I am trying to make a distributed version of ocaml, building a (software)
distributed shared memory using, which allows sharing arbitrary ML data
including closures.  On top of the DSM, we would like to provide a
primitive for remote spawning of closures, for instance:

	spawn_at : place -> (unit -> 'a) -> unit

"Spawn_at" copies the closure to the remote host identified by the
"place" and starts a new thread that runs the closure.  For this purpose,
we need a light-weight thread library.

Any help or comment is greatly appreciated.

Thank you,

Ken

Re: Thread library for ocamlopt?

[Xavier Leroy]

> Is there a plan to include the Thread module in the native compiler
> framework?  Or is there a work done with native concurrent ocaml?

The existing thread library works by context-switching at the level of
the bytecode interpreter.  This makes it highly portable to most Unix
systems, but of course the technique does not extend to the
native-code compiler.

To support native code, the thread library must be built on top of
"real" OS threads, e.g. Posix 1003.1c threads or Win32 threads.
We have such an implementation of Caml threads for Win32 (bytecode
only).  Some work is in progress to extend it to Posix threads and to
the native-code compiler.  The two main drawbacks are:

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

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

- Xavier Leroy

Re: Thread library for ocamlopt?

[Thorsten Ohl]

Xavier Leroy <Xavier.Leroy@inria.fr> writes:

> We have such an implementation of Caml threads for Win32
> (bytecode only).  Some work is in progress to extend it to
> Posix threads and to the native-code compiler.

This is good news and I'm looking forward to it!

> * 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?  Then programs would remain portable and users of
multiprocessor machines running the former three OSs could start
chasing around the FORTRAN crowd :-).

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

Cheers,
-Thorsten
-- 
Thorsten Ohl, Physics Department, TH Darmstadt --- PGP: AF 38 FF CE 03 8A 2E A7
http://crunch.ikp.physik.th-darmstadt.de/~ohl/ -------- 8F 2A C1 86 8C 06 32 6B

Re: Thread library for ocamlopt?

[Xavier Leroy]

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