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 5229BBB81 for ; Thu, 9 Mar 2006 00:44:00 +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 k28Nhv1V016756 for ; Thu, 9 Mar 2006 00:43:59 +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 k28Nhmam031397; Thu, 9 Mar 2006 10:13:50 +1030 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] STM support in OCaml From: skaller To: Brian Hurt Cc: caml-list@yquem.inria.fr, William Lovas In-Reply-To: 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> <1141855594.23909.63.camel@budgie.wigram> Content-Type: text/plain Organization: Async P/L Date: Thu, 09 Mar 2006 11:23:27 +1100 Message-Id: <1141863807.23909.151.camel@budgie.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 440F6C3D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 threads:01 posix:01 trivial:01 compiler:01 reusing:01 compiler:01 async:01 2006:98 consultants:98 wrote:01 sourceforge:01 sourceforge:01 caml-list:01 functions: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 On Wed, 2006-03-08 at 16:11 -0600, Brian Hurt wrote: > As to the cache comment: the whole caches don't have to be flushed, just > the line the mutex is on. Unfortunately that isn't correct ;( Consider: lock mutex read some data write back that data unlock mutex The problem with two threads is that 'some data' has to be invalidated too. Otherwise there is no way existing Posix software would work on a multi-processor. I couldn't believe it! That's why we tried the experiment: did the OS really invalidate the 'whole' caches, or did our trivial increment program fail, because the memory being incremented wasn't coherent? Either answer is BAD: its a lose/lose situation. The result is -- we got the right answers and the 15x slowdown which indicates that yes, really the whole** cache on both processors is being invalidated every mutex lock/unlock. Interestingly .. it should work much better with a pure FPL, there's nothing to synchronise unless the compiler did some nasty optimisations like reusing a closure for self-tail-rec functions, in which case the compiler could tell the OS which store is dirty. I wouldn't expect that to work with a C program though :) -- John Skaller Async PL, Realtime software consultants Checkout Felix: http://felix.sourceforge.net