> 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