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 03F7FBB81 for ; Wed, 8 Mar 2006 21:44:55 +0100 (CET) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k28KisPx026096 for ; Wed, 8 Mar 2006 21:44:54 +0100 Received: from [192.168.42.2] (bhurt.dsl.visi.com [208.42.141.66]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 49BA481B9; Wed, 8 Mar 2006 14:44:53 -0600 (CST) Date: Wed, 8 Mar 2006 14:45:59 -0600 (CST) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: William Lovas Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] STM support in OCaml In-Reply-To: <20060308193633.GA5460@coruscant.stwing.upenn.edu> Message-ID: References: <440DB255.1030701@asfandyar.cjb.net> <1141751708.20944.355.camel@budgie.wigram> <440DD982.8080800@asfandyar.cjb.net> <1141779125.20944.405.camel@budgie.wigram> <20060308193633.GA5460@coruscant.stwing.upenn.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 440F4246.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 lovas:01 posix:01 scalable:01 mutable:01 wrote:01 wrote:01 caml-list:01 data:02 gnu:02 commit:03 preserve:03 mutex:03 mutex:03 brian:04 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, 8 Mar 2006, William Lovas wrote: > 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. One comment I will make is that a mutex is expensive, but not *that* expensive. I just wrote a quick program (available if anyone cares) in GNU C that measures the cost, in clocks, of locking and unlocking a posix mutex. On my desktop box (AMD Athlon XP 2200+ 1.8GHz), I'm getting a cost of like 44 clock cycles. Which makes it less expensive than an L2 cache miss. At this point correctness is a much bigger concern of mine than absolute performance. A fair bit of conservative or unnecessary locking is acceptable, given than I can write a complicated and highly scalable application and know that I don't have deadlocks or livelocks. Not having race conditions would also be nice, but I don't think that's possible with mutable data. Brian