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=AWL 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 67DA9BB84 for ; Mon, 19 May 2008 20:30:28 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAAdkMUjUnw6Fb2dsb2JhbACCNY98AQwFAgQHEwObAg X-IronPort-AV: E=Sophos;i="4.27,511,1204498800"; d="scan'208";a="12767139" Received: from pih-relay06.plus.net ([212.159.14.133]) by mail3-smtp-sop.national.inria.fr with ESMTP; 19 May 2008 20:30:27 +0200 Received: from [80.229.56.224] (helo=beast.local) by pih-relay06.plus.net with esmtp (Exim) id 1JyA7u-0006to-Km for caml-list@yquem.inria.fr; Mon, 19 May 2008 19:30:26 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology? Date: Mon, 19 May 2008 19:26:15 +0100 User-Agent: KMail/1.9.9 References: <4831686F.8010903@doc.ic.ac.uk> <1211206144.11053.15.camel@flake.lan.gerd-stolpmann.de> In-Reply-To: <1211206144.11053.15.camel@flake.lan.gerd-stolpmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805191926.15156.jon@ffconsultancy.com> X-Plusnet-Relay: 3a81bd9dcaca98098979d2bc311be2db X-Spam: no; 0.00; gerd:01 stolpmann:01 subjective:01 inherently:01 parallelism:01 fairness:01 mutexes:01 frog:98 wrote:01 caml-list:01 checking:02 bugs:03 bugs:03 programming:03 locks:03 On Monday 19 May 2008 15:09:04 Gerd Stolpmann wrote: > On the contrary: Shared memory parallelization has the fundamental > disadvantage that you cannot reason about it, I have been reasoning about shared memory parallel programs for many years. > and so the only way of checking the quality of the code is testing. I often assess the correctness of my parallel codes just by reading them. > Event handing concurrency, while not giving you parallelization, is > basically sequential programming, and it is possible to reason about such > programs. Programs are parallelized in the interests of efficiency. Event handling concurrency is orders of magnitude less efficient in the context of CPU-intensive tasks that are not embarassingly parallel so it is not an alternative. > With "reasoning" I don't necessarily mean formal techniques. The more > frequent case is that the programmer thinks about the program guided by > the laws of logic. Then it is a subjective belief. > The impossibility to do this with truly parallelized code is an > important source of bugs, so I would say this code inherently more > buggy. Your remit is concurrency and not parallelism. > > i.e. you have an additional > > source of bugs, without removing the problems that are inherent > > in concurrency (e.g. deadlocks, livelocks, fairness ...). > > This is simply nonsense. Different concurrency techniques have different > problems. For example, in event handling-based concurrency you do not > need locks, hence you cannot run into deadlocks. Two agents cannot proceed because they are waiting on events from each other => they are deadlocked even though there are no mutexes. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e