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 0D06BBB81 for ; Thu, 9 Mar 2006 00:56:13 +0100 (CET) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k28NuAoB026412 for ; Thu, 9 Mar 2006 00:56:12 +0100 Received: from [192.168.1.200] (ppp9-113.lns1.syd7.internode.on.net [59.167.9.113]) by ash25e.internode.on.net (8.13.5/8.13.5) with ESMTP id k28Nu4dA081937; Thu, 9 Mar 2006 10:26:05 +1030 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] STM support in OCaml From: skaller To: Asfand Yar Qazi Cc: caml-list@yquem.inria.fr In-Reply-To: <440F6275.90301@asfandyar.cjb.net> References: <1474655.1141812700555.JavaMail.www@wwinf1632> <440EB4C2.2080102@asfandyar.cjb.net> <1141820585.20944.550.camel@budgie.wigram> <440F6275.90301@asfandyar.cjb.net> Content-Type: text/plain Organization: Async P/L Date: Thu, 09 Mar 2006 11:36:51 +1100 Message-Id: <1141864611.23909.164.camel@budgie.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 440F6F1A.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 async:01 2006:98 consultants:98 wrote:01 sourceforge:01 sourceforge:01 caml-list:01 writes:01 imperative:01 realtime:01 tend:02 concurrent:02 module:03 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 23:02 +0000, Asfand Yar Qazi wrote: > To tell the truth, I just want to be on the bleeding edge - hence my desire to > get away from this horrid imperative programming I've been indoctrinated with, > and to learn how to get the most out of tomorrows processors, which will all > be multi-core. hehe .. but procedural programming IS the bleeding edge now. > (according to Tim Sweeny anyway) STM allows writing > multithreaded apps "almost as easily as single threaded ones", so would be the > solution to the headaches one normally associates with concurrent programming. Yes, I tend to feel this is so, because it provides composition. Another way of doing this is to use channels. As a programmer I'd like a choice of techniques .. so I'd like both (and locks as well .. just in case. I still use 'goto' :) You can try out channels in Ocaml, see the Event module. This is also 'lock free' in the sense the programmer writes no locks. You also have composition, but a different kind to STM (in fact, almost looks like they're dual/control inverse). -- John Skaller Async PL, Realtime software consultants Checkout Felix: http://felix.sourceforge.net