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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 11EEDBB84 for ; Wed, 21 May 2008 10:18:51 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgBANh3M0jAXQIniGdsb2JhbACSNgEBAQ8gnTs X-IronPort-AV: E=Sophos;i="4.27,519,1204498800"; d="scan'208";a="12859210" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 May 2008 10:18:50 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m4L8IoUq026098 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 21 May 2008 10:18:50 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIBAFx3M0iKJV+LgWdsb2JhbACSNgEBECAFnTw X-IronPort-AV: E=Sophos;i="4.27,519,1204498800"; d="scan'208";a="12515675" Received: from tart.dcs.qmul.ac.uk (HELO mail.dcs.qmul.ac.uk) ([138.37.95.139]) by mail1-smtp-roc.national.inria.fr with ESMTP; 21 May 2008 10:18:50 +0200 Received: from new8-pc.dcs.qmul.ac.uk ([138.37.88.113]) by mail.dcs.qmul.ac.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JyjX6-0007kt-62; Wed, 21 May 2008 09:18:49 +0100 Message-ID: <4833DAE7.20409@doc.ic.ac.uk> Date: Wed, 21 May 2008 09:18:47 +0100 From: Martin Berger User-Agent: Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: "Ulf Wiger (TN/EAB)" , 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> <48328059.2070007@ericsson.com> In-Reply-To: <48328059.2070007@ericsson.com> 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 4833DAEA.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; event-based:01 parallelism:01 event-based:01 wholly:98 wrote:01 caml-list:01 data:02 face:97 programming:03 concurrency:04 concurrency:04 reordering:04 passing:05 problem:05 shared:06 Ulf Wigner wrote: > Going back to Jon's observation that you cannot exploit > multicore with event-based programming, I'm inclined to > agree, even though I think that message-passing concurrency > is quite suitable for making use of multiple cores (albeit > addressing a wholly different problem from data parallelism). As more and more core will be put on a single chip, most cores will be communicating via a network on chip. Hence message passing is unavoidable. And if it is unavoidable then maybe we should have it all the way. > When scaling up message-passing (or event-based) concurrency, > you have to do one of two things: > > 1) ensure that your code is stable in the face of timing > variations and message reordering > 2) calculate the entire event/state matrix That's right. Martin