From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 0E17EBBAF; Tue, 27 May 2008 11:35:02 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgECAPtxO0jAXQIniGdsb2JhbACBVZBmAQEBDyCaNA X-IronPort-AV: E=Sophos;i="4.27,548,1204498800"; d="scan'208";a="11165135" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 27 May 2008 11:35:01 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m4R9YuOa014318 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK); Tue, 27 May 2008 11:35:01 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMCAKJyO0iKJV+LgWdsb2JhbACBVZBmAQEQIAWaKw X-IronPort-AV: E=Sophos;i="4.27,548,1204498800"; d="scan'208";a="13087203" Received: from tart.dcs.qmul.ac.uk (HELO mail.dcs.qmul.ac.uk) ([138.37.95.139]) by mail3-smtp-sop.national.inria.fr with ESMTP; 27 May 2008 11:35:01 +0200 Received: from host81-152-51-93.range81-152.btcentralplus.com ([81.152.51.93] helo=xila.local) by mail.dcs.qmul.ac.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1K0va7-0004Eb-E3; Tue, 27 May 2008 10:35:00 +0100 Message-ID: <483BD594.7050504@doc.ic.ac.uk> Date: Tue, 27 May 2008 10:34:12 +0100 From: Martin Berger User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Damien Doligez Cc: caml-list Subject: Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology? References: <200805181735.50621.jon@ffconsultancy.com> <4831686F.8010903@doc.ic.ac.uk> <1211206144.11053.15.camel@flake.lan.gerd-stolpmann.de> <4833D7E8.8060502@doc.ic.ac.uk> <4EDC5A3B-DFD2-47EA-9C22-F0B355D7BBC7@inria.fr> In-Reply-To: <4EDC5A3B-DFD2-47EA-9C22-F0B355D7BBC7@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCS-Interface-Port: 465 X-DCS-Auth-User: martinb (person) X-Miltered: at concorde with ID 483BD5C0.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; model:01 neglecting:01 model:01 abstraction:01 abstraction:01 broadcasting:98 broadcasting:98 caml-list:01 century:98 parameter:02 asynchronous:03 concurrency:04 concurrency:04 depends:04 processors:04 >> Here I disagree. Shared memory concurrency is a specific form >> of message passing: Writing to a memory cell is in fact sending >> a message to that cell carrying two items, the new value and a >> return channel that is used to inform the writer that sending >> has succeeded, and likewise for reading. > > This is completely wrong. A few machines have a simple model like > that, but they were all built in the last century. Nowadays, writing > to memory is more like broadcasting a message and having no idea when > it will arrive at each destination. And if you write to another piece > of memory, you don't know in what order the updates will become > visible to a given processor. > > You are neglecting a very important parameter, which is called the > "memory model" of your multiprocessor. But broadcasting is a form of message-passing too! I was not forgetting the memory model, I was just arguing at a higher level of abstraction. Moreover, asynchronous message-passing, which is the dominant for of message passing studied in concurrency theory, doesn't make guarantees about the order of communication. Exactly what kind of message passing is appropriate depends on the used processors and on the chosen level of abstraction. Martin