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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 52610BB81 for ; Wed, 8 Mar 2006 20:22:08 +0100 (CET) Received: from hugh.cs.washington.edu (hugh.cs.washington.edu [128.208.2.43]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k28JM6JC028796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 8 Mar 2006 20:22:07 +0100 Received: from [128.208.2.33] (gerald.cs.washington.edu [128.208.2.33]) by hugh.cs.washington.edu (8.13.5/8.13.5/1.5) with ESMTP id k28JM5Wt020489 for ; Wed, 8 Mar 2006 11:22:05 -0800 (envelope-from djg@cs.washington.edu) Message-ID: <440F2ED8.8040108@cs.washington.edu> Date: Wed, 08 Mar 2006 11:22:00 -0800 From: Dan Grossman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] STM support in OCaml References: <1474655.1141812700555.JavaMail.www@wwinf1632> <1141817549.10771.63.camel@localhost.localdomain> <1141819496.20944.534.camel@budgie.wigram> In-Reply-To: <1141819496.20944.534.camel@budgie.wigram> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 440F2EDE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 posts:01 bytecode:01 bytecode:01 scheduler:01 ocaml:01 native-code:01 scheduler:01 combinators:01 parallelism:01 threads:01 computations:01 threads:01 gerd:01 stolpmann:01 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 Just to chime in on this thread briefly as an AtomCaml author: * The posts have described AtomCaml fairly accurately (exploits uniprocessor, works only for bytecode, is integrated with the bytecode thread scheduler). * AtomCaml is not "officially" supported; it demonstrates that STM support in OCaml is "not that hard". That said, constructive feedback is welcome. * From my perspective, the things missing are: 1. native-code support (and yes this involves communicating with the kernel scheduler) 2. STM-Haskell style combinators (I see no major problems here). 3?. We should be clear that OCaml does not provide "true parallelism" (i.e., multiprocessing). The point of AtomCaml is to show how fast STM can be given that. 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. * Multiple threads can provide isolation (if one task must abort it can throw an exception which terminates only one thread). --Dan skaller wrote: > On Wed, 2006-03-08 at 12:32 +0100, Gerd Stolpmann wrote: > > >>Anyway, I think this question is misleading. The point is not to >>establish locking schemes that use the hardware better (i.e. that are >>faster), but to help programmers writing correct code. > > > My aim would be to do both -- they're not independent. > Who cares about concurrency if not to try to do some job faster? > And of course it's no good if you do the wrong thing faster :) >