From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 57072BC3F for ; Sat, 30 Oct 2004 03:07:38 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i9U17bun003647 for ; Sat, 30 Oct 2004 03:07:37 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA00261 for ; Sat, 30 Oct 2004 03:07:37 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i9U17ZxI003637 for ; Sat, 30 Oct 2004 03:07:36 +0200 Received: from [192.168.1.200] (ppp217-99.lns1.syd3.internode.on.net [203.122.217.99]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i9U17TOU080821; Sat, 30 Oct 2004 10:37:30 +0930 (CST) Subject: Re: [Caml-list] atomicity guarantees for threaded code From: skaller Reply-To: skaller@users.sourceforge.net To: David Brown Cc: Ker Lutyn , caml-list In-Reply-To: <20041030003249.GA11524@old.davidb.org> References: <20041029163907.36287.qmail@web40611.mail.yahoo.com> <20041029215027.GA9504@old.davidb.org> <1099094075.11063.215.camel@pelican.wigram> <20041030003249.GA11524@old.davidb.org> Content-Type: text/plain Message-Id: <1099098448.11063.284.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 30 Oct 2004 11:07:28 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4182E959.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4182E957.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 wrote:01 wrote:01 threads:01 byte:01 alignment:01 ocaml:01 aligned:01 aligned:01 occuring:01 swapped:01 alignment:01 ocaml:01 glebe:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Sat, 2004-10-30 at 10:32, David Brown wrote: > On Sat, Oct 30, 2004 at 09:54:37AM +1000, skaller wrote: > > > > As long as the reference write is atomic, which it is going to be, I would > > > suspect this is safe. It probably would even be safe if multiple threads > > > updated the reference, but you might just drop entries. > > > > It isn't clear though. On x86 you can have 1 byte alignment > > for an address. What happens if: > > But, a reference in ocaml will always be in a block, which will always be > aligned. On what boundary? > Even x86 will be atomic with a 32-bit transfer that is aligned. But perhaps not a 64 bit one. Part of my argument was that it is implementation dependent. In particular, a page fault is only one kind of interrupt. It is possible, for example, to get another IRQ right in the middle of a transfer from memory .. and interrupt the transfer. And that IRQ could actually cause the page from which the load was occuring to be swapped out .. meaning it may not be necessary to be near a page boundary to get a page fault... and thus the alignment may not matter. As I indicated some instructions on some processors aren't atomic, particularly CISC machines.. it may be that loading and storing isn't such an interruptible instruction, but I'm not sure .. without checking the x86 hardware manual. Certainly 48 bit loads on a x386 can cause segmentation faults (I mean, the whole thing is *designed* to do that) .. however these don't normally apply to Unix like systems that aren't capable of using segmented addressing (in user space). So I would guess you are right for all OS Ocaml supports. Even so I'd be loath to rely on such a guess until the Ocaml team asserted the guarrantee in the manual. I wouldn't do it in C, because of the wide class of platforms it applies to .. but Ocaml doesn't intend to handle such a wide class. If the guarrantee was made, it could simplify some Ocaml programming significantly, and thus possibly improve performance. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net