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 5B84ABB81 for ; Thu, 9 Mar 2006 04:18:50 +0100 (CET) Received: from cenn.mc.mpls.visi.com (cenn.mc.mpls.visi.com [208.42.156.9]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k293InEt004079 for ; Thu, 9 Mar 2006 04:18:50 +0100 Received: from [192.168.42.2] (bhurt.dsl.visi.com [208.42.141.66]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id 2535C81B0; Wed, 8 Mar 2006 21:18:49 -0600 (CST) Date: Wed, 8 Mar 2006 21:19:56 -0600 (CST) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: skaller Cc: caml-list@yquem.inria.fr, William Lovas Subject: Re: [Caml-list] STM support in OCaml In-Reply-To: <1141863807.23909.151.camel@budgie.wigram> 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> <1141855594.23909.63.camel@budgie.wigram> <1141863807.23909.151.camel@budgie.wigram> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 440F9E99.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 threads:01 posix:01 trivial:01 snoop:98 mesi:98 wrote:01 caml-list:01 writes:01 caches:01 caches:01 increment:02 flush:03 generally: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 Thu, 9 Mar 2006, skaller wrote: > 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? Generally both the lock get and lock remove need to do a memory barrier, and force all writes to complete to cache. Once in cache, the cache's do cache coherency. The caches snoop the memory traffic- and if someone is reading memory that the cache knows is more up to date in that cache than in memory, the read is satisified from that cache and not from memory- and the cache updates memory as well at the same time. I'm simplifying enormously here, but the end result is that no, you don't need to flush the entire cache on lock release. Google "cache coherency" or "MESI" for more information. Brian