threads library in Objective Caml

threads library in Objective Caml

[Pawel Wojciechowski]

The potential advantage of threads is that on a multiprocessor shared memory 
machine, each thread can run on a different processor. However, in the (O)Caml 
documentation is written as follows: "The `threads' library is implemented
by time-sharing on a single processor. It will not take advantage of multi-
-processor machines. Using this library will therefore never make programs 
run faster".

When writing concurrent porgrams, it is essential to handle concurrency 
properly, and that means assigning threads dynamically.  It is vital that
the threads are recognised at kernel level for independent allocation of
processor resource (otherwise it's "block one, block all", which is
intolerable). 

Assuming that the threads library of the (O)Caml is implemented by using 
the POSIX Unix thread library, in the light of the previous paragraph, it 
seems to me that using threads in programs written purely in Caml is less
powerful (in terms of the program behaviour on multi-processor architecures)
that using threads in a program written in C. Could you briefly explain 
this ?

On the other hand, on a single processor architecture, programs written
in Caml or C should take advantage of using threads library in exactly the 
same way. Am I right?

Pawel

Re: threads library in Objective Caml

[Francois Rouaix]

> The potential advantage of threads is that on a multiprocessor shared memory 
> machine, each thread can run on a different processor.
Also, even on a single processor, threads are useful for highly IO/network
dependant programs (such as web tools and distributed computation). That's
where we have used them mostly.

> Assuming that the threads library of the (O)Caml is implemented by using 
> the POSIX Unix thread library, in the light of the previous paragraph, it 
> seems to me that using threads in programs written purely in Caml is less
> powerful (in terms of the program behaviour on multi-processor architecures)
> that using threads in a program written in C. Could you briefly explain 
> this ?
There are two different implementations. One (the threads library), usually
called bytecode threads, doesn't use Posix threads at all. It's user-level
threads, taking advantage of the bytecode approach (but also with its assorted
limitations). It's only real use is for IO-bound programs (e.g. my V6 web
proxy, or web crawler).

The other implementation (otherlibs/systhreads) relies on Posix 
(preferably kernel) threads. I'll quote a previous answer of Xavier on
that same topic (since he's away for some time):

XL> The good news is that OCaml already has support for native threads 
XL> (as opposed to bytecode-level threads), both for Win32 and for POSIX 
XL> threads. Look in the otherlibs/systhreads subdirectory. We don't 
XL> advertise the POSIX binding because so few Unix actually implement 
XL> POSIX 1003.1b, but it's there.

XL> The bad news is that most of the OCaml runtime is still not 
XL> thread-ready, in particular the memory manager, so we have to put a 
XL> big critical section around the whole bytecode interpreter and GC. 
XL> What this means is that at any time, at most one thread can be 
XL> executing Caml code, or allocating, or garbage collecting. Other 
XL> threads are either stopped or executing foreign (non-Caml) code.

XL> As you can see, this is a very quick hack, but it works relatively 
XL> well for the kind of applications we're interested in: asynchronous I/
XL> O in several threads. In this case, most threads are blocked most of 
XL> the time on I/O calls, so the global mutual exclusion does not harm 
XL> parallelism too much.

XL> Of course, it's a terrible idea for doing intensive computations on a 
XL> multiprocessor. Essentially, this scheme prevents you from taking 
XL> advantage of more than one processor!

XL> We did some work on a truly concurrent garbage collector and runtime 
XL> system for Caml Light, back into 1991-1992. This eventually became 
XL> Damien Doligez's PhD thesis (see
XL> http://pauillac.inria.fr/~doligez/caml-light-gc/
XL> for the full story).

XL> Damien's design was (and still is) very nice, but to my great regrets 
XL> he did not bring his implementation to completion. 

Finally,
> On the other hand, on a single processor architecture, programs 
> written in Caml or C should take advantage of using threads library 
> in exactly the  same way. Am I right? 
I guess so. Except that bytecode threads are essentially portable, even
if you don't have Posix threads available.


--f

threads library in Objective Caml

[Frank Christoph]

>>>>> "Pawel" == Pawel Wojciechowski <Pawel.Wojciechowski@cl.cam.ac.uk> writes:
> The potential advantage of threads is that on a multiprocessor shared memory
> machine, each thread can run on a different processor. However, in the
> (O)Caml documentation is written as follows: "The `threads' library is
> implemented by time-sharing on a single processor. It will not take
> advantage of multi- -processor machines. Using this library will therefore
> never make programs run faster".

You make it sound like the only point of threads is to take advantage of
parallelism when the program is running on a multiprocessor machine.  A lot of
people use threads for reasons that have nothing to do with (objective notions
of) performance, for example in GUI programming.  By your logic, there
would seem to be no point in emulating concurrency on a sequential machine at
all.

-- 
Frank Christoph                 Next Solution Co.      Tel: 0424-98-1811
christo@nextsolution.co.jp                             Fax: 0424-98-1500

Re: threads library in Objective Caml

[pcuoq]

I think that the part of the documentation you
refer to deals with the thread library of the
bytecode compiler, implemented by time-sharing
on the virtual machine.

There is however a thread library using Unix threads 
(in otherlibs/systhreads) but it has the same
bad behavior on multi-processor machines :
There is (almost everytime) only one caml thread
running.  This is ensured by a mutex shared among
caml threads.  The mutex is released only at safe
points of the execution.

In particular it is released each time that the
current thread could block.

This explains the behavior of caml programs on
MP machines.

  Pascal