From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 2947EBB81 for ; Wed, 8 Mar 2006 22:41:42 +0100 (CET) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k28Lfei3000985 for ; Wed, 8 Mar 2006 22:41:41 +0100 Received: from [192.168.1.200] (ppp9-113.lns1.syd7.internode.on.net [59.167.9.113]) by smtp1.adl2.internode.on.net (8.13.5/8.13.5) with ESMTP id k28LfTnH067208; Thu, 9 Mar 2006 08:11:30 +1030 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] STM support in OCaml From: skaller To: Dan Grossman Cc: caml-list@yquem.inria.fr In-Reply-To: <440F2ED8.8040108@cs.washington.edu> References: <1474655.1141812700555.JavaMail.www@wwinf1632> <1141817549.10771.63.camel@localhost.localdomain> <1141819496.20944.534.camel@budgie.wigram> <440F2ED8.8040108@cs.washington.edu> Content-Type: text/plain Organization: Async P/L Date: Thu, 09 Mar 2006 09:10:19 +1100 Message-Id: <1141855819.23909.66.camel@budgie.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 440F4F94.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 threads:01 computations:01 threads:01 synchronous:01 synchronous:01 mlton:01 haskell:01 callbacks:01 inverted:01 inverting:01 sockets:01 parallelism:01 async:01 2006:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Wed, 2006-03-08 at 11:22 -0800, Dan Grossman wrote: > As for "why concurrency if not to run faster", there _are_ other reasons > for certain applications: > * Multiple threads are a natural match for computations that are > naturally decomposed into multiple control contexts. Yes, but one only uses *pre-emptive* threads here if the language fails to provide control inversion/synchronous threads. With synchronous threads you have interleaving, but no concurrency. Felix, MLton, and Haskell provide synchronous threads. Pre-emptive threads are less useful by comparison due to their exceptionally poor performance on most OS, limitations to their numbers, and the need for use of interlocking primitives (mutex etc) which are generally not required with synchronous threads. The latter not only reduces performance, it also makes programming very much more difficult. In particular, STM isn't as useful with synchronous threads. In fact most uses of 'multiple control contexts' call for control inversion NOT pre-emption or concurrency: what's required for the 'natural match' is to turn the program 'inside out'. Actually the idea extends to asynchronous control as well: asynchronous callbacks, signals, or interruptions, can also be interleaved and represented in control inverted form. Felix is now doing both. The effect is that as in C you would write 'read channel data' or 'write channel data' in multiple threads. But actually by control inverting this is turned into non-concurrent callback/event driven code. There are indeed 'logical threads of control' but no concurrency. In Felix for example, we do use one thread for sockets to synchronise the OS with the program: the end user, however, can ignore this and write a web server supporting a million active connections and not use a single bit of 'concurrency'. [We could use pollling .. and indeed within the thread we are: with epoll, kqueue, or io completion ports] I do agree with what you're saying -- yes threads are a natural fit for many problems. But 'concurrency' is generally NOT what is required, and is in fact a serious obstacle to both performance and ease of programming. But it all depends on what you mean by 'concurrent'. The word of course really does imply parallelism: con-current means literally 'at the same time' which is generally impossible on a uniprocessor (except perhaps for DMA, H/W accelerated graphics, etc .. but then really you do have more than one processor :) Anyhow all this is just to say: lets not confuse the need for Concurrency with the need for Control Inversion. -- John Skaller Async PL, Realtime software consultants Checkout Felix: http://felix.sourceforge.net