From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA29235 for caml-redistribution; Fri, 18 Apr 1997 21:29:07 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA01076 for ; Mon, 14 Apr 1997 19:06:47 +0200 (MET DST) Received: from madiran.inria.fr (madiran.inria.fr [128.93.8.77]) by concorde.inria.fr (8.7.6/8.7.3) with ESMTP id TAA12281; Mon, 14 Apr 1997 19:06:46 +0200 (MET DST) Received: from madiran.inria.fr (localhost.inria.fr [127.0.0.1]) by madiran.inria.fr (8.7.4/8.6.6) with ESMTP id TAA17965; Mon, 14 Apr 1997 19:06:41 +0200 Message-Id: <199704141706.TAA17965@madiran.inria.fr> X-Mailer: exmh version 1.6.4 10/10/95 From: Francois Rouaix To: Pawel Wojciechowski cc: caml-list@inria.fr Subject: Re: threads library in Objective Caml In-reply-to: Your message of "Mon, 14 Apr 1997 10:35:10 BST." Reply-To: Francois.Rouaix@inria.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Apr 1997 19:06:41 +0200 Sender: weis > 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