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 ED482BB81 for ; Wed, 8 Mar 2006 20:36:36 +0100 (CET) Received: from yavin.stwing.upenn.edu (YAVIN.STWING.upenn.edu [165.123.132.64]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k28JaZOq017947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 8 Mar 2006 20:36:36 +0100 Received: from localhost (localhost [127.0.0.1]) by yavin.stwing.upenn.edu (Postfix) with ESMTP id 129E91BDD for ; Wed, 8 Mar 2006 14:36:35 -0500 (EST) Received: from yavin.stwing.upenn.edu ([127.0.0.1]) by localhost (yavin.stwing.upenn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06861-02 for ; Wed, 8 Mar 2006 14:36:34 -0500 (EST) Received: from coruscant.stwing.upenn.edu (coruscant.stwing.upenn.edu [165.123.132.62]) by yavin.stwing.upenn.edu (Postfix) with ESMTP id CDA891BD3 for ; Wed, 8 Mar 2006 14:36:34 -0500 (EST) Received: by coruscant.stwing.upenn.edu (Postfix, from userid 5302) id 9860BE51D; Wed, 8 Mar 2006 14:36:34 -0500 (EST) Date: Wed, 8 Mar 2006 14:36:34 -0500 From: William Lovas To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] STM support in OCaml Message-ID: <20060308193633.GA5460@coruscant.stwing.upenn.edu> Mail-Followup-To: caml-list@yquem.inria.fr References: <440DB255.1030701@asfandyar.cjb.net> <1141751708.20944.355.camel@budgie.wigram> <440DD982.8080800@asfandyar.cjb.net> <1141779125.20944.405.camel@budgie.wigram> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1141779125.20944.405.camel@budgie.wigram> User-Agent: Mutt/1.5.6i X-Virus-Scanned: amavisd-new at stwing.upenn.edu X-Miltered: at concorde with ID 440F3243.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; lovas:01 wlovas:01 stwing:01 upenn:01 ocaml:01 semantics:01 haskell:01 2006:98 2006:98 wrote:01 wrote:01 caml-list:01 programming:03 commit:03 preserve: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, Mar 08, 2006 at 11:52:05AM +1100, skaller wrote: > On Tue, 2006-03-07 at 19:05 +0000, Asfand Yar Qazi wrote: > > As for claim 1. "Lock-free" doesn't mean what you think it does. > > I know what STM does, thank you: I intend to implement it > myself in my own programming language. Maybe you should > read more carefully. > > I said "protected by a mutex under the hood." which means > sure, the programmer is not writing locks, but they're used > in the implementation and the associated costs are still paid. As the quoted paper said, though, some running transaction can always commit -- so not all of the associated costs are still paid. In particular, the cost of potential non-termination due to deadlock or livelock is not paid. It doesn't matter that there's a mutex under the hood, since it's used only in such a way as to preserve the property that some transaction can always complete. > I really hate it when people try to throw papers against > simple logic. I said what the tradeoffs where: In this case, i think the paper was right :) Its statement of "lock-free"ness was with regards to semantics, not performance. You may be correct that there is some other property, regarding performance, that the STM Haskell implementation does not have, but it is not what their paper calls "lock-free". William